Auto linking domain account to live IDs - windows-8.1

There's any way to link domain account to live ID?
I've seen that when you link domain account to live ID, in registry this keys are generated:
[HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities\myliveIDaccount#outlook.com]
"Keywords"="Associated"
"CID"="6213e28fcbefc3ed"
"AssociatedCount"=dword:00000001
"AccountsCount"=dword:00000002
"LatestDPAPIKeyVersion"="1387274538"
[HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities\myliveIDaccount#outlook.com\S-1-5-21-95946...]
"AccountType"="DomainConnected"
"Flags"="40000643"
"FirstName"="my"
"DisplayName"="id account"
"LastName"="test"
"Keywords"="Associated;Connected"
"LatestDPAPIKeyVersion"="1387274538"
"ChildFlags"="00000001"
"DefaultCredSaved"="Persisted"
If i import that keys to another PC, everything is working fine: domain account is linked to live ID and i can access to Store.
But, if i import that keys to another PC with "LatestDPAPIKeyVersion" and "CID" modified, the domain account seems to be linked to live ID but i have seen two differents behaviors:
First time, i couldn't enter the Store. It was stuck on the green screen, loading the store for more then 30 minutes.
Second time, i entered the Store, but when I tried to download app it asked me the password
So here comes the final cuestion:
Knowing all that, is there a way to link domain accounts to live ID accounts in an automatic way, assuming we know the live ID accounts and their password?
Thanks!

Related

How to identify a client with nodejs/express?

I am creating a web app that offers a membership access with a trial period. However, I need to be sure the users cannot create a new account with other credentials just to get another trial period and so on.
I was considering using req.connection.remoteAddress; to know if a client already claimed its trial but I am not sure this ip address will be unique to a specific machine.
Any idea ?

Azure SSL certificate shows Guest User Error

I have purchased an SSL cert for my site and the cert has three steps you need to do in order to have it fully configured. The first step is "Key Vault Status" which I then click on and it shows the following error:
You do not have permission to get the service prinicipal information needed to assign a Key Vault to your certificate. Please login with an account which is either the owner of the subscription or an admin of the Active Directory to configure Key Vault settings.
This is very confusing because I am the owner of this subscription and I also went and created a new Key Vault just in case it was due to not having one created in the first place. In addition I checked the Access Control for this cert and I am also listed as Owner.
Any help is appreciated.
Ok, so I finally got to the bottom of it - I'll outline the story here as this was the solution but may not work for everyone.
When I first created my Azure account I did so under email address 1
A few years later I had migrated most of my email to email address 2. To get status updates and other things I transferred the subscription to email address 2.
Every other service has worked fine accept for this SSL issue as well as not being able to buy a support plan (it popped open an email app to send to email address 1)
In speaking with the AzureSupport twitter account they agreed that it was strange and arranged for a one time ticket for support.
The support agent asked me to check my Access Policies for the Key Vault I had created. This showed that email 1 is indeed a user in the Azure Active Direction and they mentioned that I'd need to have the admin add it. Since I had noticed the irregularities with email address 1 showing up in the URL and in the email for adding support I logged into Azure using email address 1 and went to Azure Active Directory->Users under that account.
I then selected the guest account, selected Directory Role, and added a new role of Application Administrator. Now all of it is working as expected!
My subscription was attached to employer Active Directory and I can't change my role in it.
I solve this problem by creating my own Active Directory and by moving subscription to this AD.

Kentico 10 Contact activity logged against previously logged out user

We have a Kentico 10 website using custom WIF authentication. That is all working fine. I can see that the authenticated user details match what is expected.
I tried enabling the online marketing - contact tracking and then discovered that even though I had logged out with one account and then logged in with another account the new user's activity was being logged as if the first user had performed it.
The only that works reliably is using a delete cookie plugin in chrome which isn't a good solution for production.
I tried expiring the existing cookies for the domain and then found after logging out and back in again with a new user that all the new activity was being logged as public anonymous user.
Is there anything I can add to signout or login to ensure that the correct Contact is being tracked against. Different users should be able to use the same browser logging out and back in again without this contact activity going against the wrong person.
The contact cookie is stored per user account on a computer. So if you're simply logging in and out of Kentico this activity will not change your contact cookie. Kentico sees you as the same contact even though you are authenticating with a different user account.
Kentico Contacts and Users are not synonymous although they can have a link to one another. So I'd expect if the user account with linked with a contact you may see different activity for that particular contact. The only way a contact is linked to a user account is if one of the 3 activities happen:
Registers on a website
Signs in with a user account
Fill in customer data while making a purchase
So even though you're doing #2, I'm guessing something unique is happening since you're doing some testing on the local machine. Check out the documentation about contacts and linking to user accounts. To test or see if a user is linked to a contact, go to Contact Management, manage a contact and click on the Membership>Users tab. If see a user account linked to the contact then that contact is linked. If you don't see one then that particular contact is not linked and you'll experience the issues you're explaining.

Every claim from Windows ID comes back as the same thing

I am experimenting with using the Access Control Service in Azure. I have most of it working, I can log in using any of the providers but I'm having an issue with the claims against the WindowsLive provider. With the google provider I am able to get such useful information as the person's name and their e-mail address. I put similar claims in for WindowsLive but I get back the same value for every single claim. I've tried
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (I expected this to be gobbildygook)
http://schemas.xmlsoap.org/claims/EmailAddress
http://schemas.xmlsoap.org/claims/CommonName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
each of these return something like :oULpbTv2AMylPasgUOsLZAHjaBYtxldrU+gg3aS5nI4=
Now I'm pretty sure that isn't my e-mail address because it wouldn't fit on my business card and I know it isn't my name because my mother isn't Welsh and wouldn't support me being named as if I were.
I followed the tutorials found at http://robbincremers.me/2012/02/22/using-windows-azure-access-control-service-to-provide-a-single-sign-on-experience-with-popular-identity-providers/ and http://msdn.microsoft.com/en-us/library/gg185914.aspx to get this set up.
Is there some way that I can get information other than an identifier out of WindowsLive? Maybe the issue is related to my not setting up an encryption certificate?
Edit: After some searching I found Are any other claims available from Windows Live ID via the ACS 2.0 identity provider? which suggests that my attempts to get more information out of WindowsLiveID is a hopeless quest. I will just prompt users for information when they log in for the first time.
The windows live provider doesn't give you anything other than a unique providerId. This is unique to your application and the user's windows live id. Google is a little better in that they give you the users name as well as their email.
The way I solved this is that on account creation in my application I just collect any information from the user that I need in addition to what is provided from the claims. So if they are using Google then i pre-populate their Email and name on my "Create Account" form. If they're using Windows then the form fields are just blank and they have to fill out the necessary info to finish creating their account. It works pretty well.

Anonymously linking user data to analytics

I would like to collect analytics on multiple visits from a logged in user, if they opt in.
But I would really like to do it in a way that only the user can link their user account to the anonymised analytics entry. This means, when the user is logged in, they can manage the analytics information stored from their visits, but site administrators won't be able to link the analytics entries to that account (the analytics data and user data is of course stored separately)
Ignoring implicit links in the analytics data (such as user identifying URLs etc), what would be the best way to implement this? Is it too dangerous to use a secure hash of the user's password and account ID to identify the analytics information? (the site administrators won't have the user's password, so won't be able to link the records).
You've dressed this up so that linking a user account to data is not predicatable - but that doesn't mean it that the information is therefore hidden. Regardless users will be making a requset based on a key, which is exclusively derived from their account - so really its just security by obscurity. Since it must be possible for the system to reconcile the users identity with the key against which the data is stored it is therefore possible for someone with backend access to derive the association - even if only at the time of access.
The only way to prevent this is to store the data on a machine where these admins don't have access.

Resources