Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a web app that is front-ended by ISA, natively authenticating against AD. All users currently log on with sAMAccountName. I would like to allow users to provide a personal email address and be able to authenticate against this instead.

From what I understand the AD userPrincipalName is typically used for an internally generated logon name, which by convention, is often their internally generated email address. The web app that I have is web scale (circa 3 million accounts*) and not an internal, corporate app, so the email addresses will be from diverse domains. Can I just set the AD userPrincipalName attribute to the user's email address, and then will ISA natively authenticate against this attribute instead? I heard rumours of AD having a maximum number of domain suffixes that it allows in AD userPrincipalName...? (presumably it catalogues them).

[*I realise that AD is not the ideal authentication directory for a user population of this scale.]

share|improve this question

migrated from stackoverflow.com Oct 26 '11 at 14:25

This question came from our site for professional and enthusiast programmers.

3 Answers 3

up vote 1 down vote accepted

So long as the values are unique, the answer is yes.

share|improve this answer
    
Interesting... I thought upn suffix needs to be setup so that AD knows from the suffix which domain to talk to. I just had a quick check on my test domain. You seem to be right that upn suffix does't need to setup and it still work in my single domain environment. I still wonder if the whole thing can still work if there is a forest trust and multiple forests are involved. –  Harvey Kwok Oct 19 '11 at 6:40
    
Ok, just tested. The authentication with different upn suffixes are done on local forest only. If we want to route authentication request on particular upn suffix to different forests, upn suffixes setting need to be setup probably. –  Harvey Kwok Oct 19 '11 at 16:44
    
You're correct, this is only necessary for upn suffix routing w/ forest trusts. There's a ~1,300 value limit there. –  Brian Desmond Oct 21 '11 at 2:03

userPrincipalName attribute can be set to any values using ADSIedit. However, to make the userPrincipalName useful, you have to set it to some defined format. It should always look like this username@domain.name. Also, you cannot set arbitrary domain.name. Otherwise, Windows cannot look up correct domain controller to do the authentication.

The value of userPrincipalName of an AD user can be edited in Active Directory User and Computer. The value is shown under User logon name under the Account tab. From this property page, you immediately find that you can only edit the username part of the UPN. Windows give you a combo box for the domain.name part. Normally, there is only one option there, which is your AD domain name.

In order to use some other values for domain.name, you need to add additional domain suffixes by using Active Directory Domains and Trusts. See here. Note that only domain administrator can add additional domain suffixes for the domain. Once you add the additional domain suffixes, you can go back to Active Directory User and Computer. The user property page should now allow you to choose the newly added domain suffixes along with the default AD domain name.

share|improve this answer

I tested loading an ad with 2000 users that all had unique userprincipalNames. They all had unique domains too which had not been registered in AD Domains & Trusts (i.e. so they don't appear in the drop-down in Active Directory User and Computers)

I then tested logging on as one of these users with a userprincipalname to a web app that is front-ended by ISA, natively authenticating against AD and it worked with no problems.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.