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.

We currently have a Windows Server 2008 R2 set up with the domain, for example "abc.co.uk"

We have recently purchased a .co domain name for example "abc.co"

How do we go about having some kind of alias for users logging on to the network.

So for example the current username is...first.last@abc.co.uk but if the user enters first.last@abc.co, it logs on to to the same account under the .co.uk domain name?

What will be the best way of going about this?

Many thanks

share|improve this question

migrated from stackoverflow.com Jul 28 '10 at 13:18

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

    
I'm not sure if you're confusing Internet domains (for email, websites, etc.) with Active Directory domains (for authentication, directory services, etc.): normally you'd setup an abc.local domain for Active Directory and use your Internet domains for e-mail, etc. –  gravyface Jul 28 '10 at 13:28
    
I've commonly seen people using split DNS to use their Internet domain for their AD domain. It has it's pros and cons like any other decision. –  Chris S Jul 28 '10 at 13:30
1  
More cons, but yes, I've seen that too. I think I read somewhere that Microsoft is now recommending you not use your Internet domain (or a public TLD) for your AD setups. –  gravyface Jul 28 '10 at 13:43
1  
Correct, it is recommended that you not use a public domain name for your AD domain. If you want to use the new direct access features of AD the internal domain name and the public name MUST be different. –  mrdenny Jul 28 '10 at 19:19
1  
I see no "pros" for "split DNS". It creates make-work and offers no benefits. Microsoft has never, that I'm aware of, recommended using your Internet domain name as your AD domain name. My experience goes back to the "Microsoft Official Curriculum" MCSE training materials from late 1999, and even then they were suggesting using a third-level name of an Internet domain name you control, or a second-level Internet domain name that you don't use for any Internet-accessible resources. –  Evan Anderson Jul 28 '10 at 20:47

2 Answers 2

Each user account in an Active Directory domain has a single "samAccountName" and a single "userPrincipalName". The "samAccountName" is the old-style NT 4.0 username-- "bob", "alice", etc. The "userPrincipalName" is a name that looks like an email address "alice@company.com" (but isn't an email address).

"userPrincipalNames", or UPN's, have an account name part (before the "@" sign) and a suffix part (after the "@" sign). An arbitrary number of suffixes, which bear no relationship whatsover to the names of any domains in the Active Directory forest, can be created in an Active Directory forest. After you've created a UPN suffix it can be assigned to users. The relationship of UPN suffixes to each user's "userPrincipalName" is configured on a user-for-user basis. You can have a single Active Directory domain in a forest with 3 UPN suffixes configured, and users in that domain can have their individual UPN suffix set, arbitrarily, to any of the forest-wide UPN suffixes w/o affecting any other users.

The limitations are that each user can have a single UPN suffix applied at a time, and no two users can have the same UPN (account name + suffix) even if they're in different domains in the forest (because UPNs must be unique forest-wide).

"userPrincipalNames" bear a resemblence to email addresses but have nothing to do with email addresses. Typically, though, you'll want to choose a suffix and account naming convention such that the user's UPN matches their email address. This makes things very convenient and less confusing for the users.

For your application, it sounds like you should create an "@abc.co" UPN suffix in your forest (using the "Active Directory Domains and Trusts" tool) and then assign that UPN suffix to users who you want to be able to logon with a "user@abc.co" UPN.

share|improve this answer

Umm... I could be completely offbase, but I thought that's what UPN's were for? You can create a new UPN for the domain as: abc.co and that will create a new UPN for each user as: username@abc.co. The user will then be able to log on to the domain as username@abc.co.


EDIT

I think Chris S and I are saying the same thing but in slightly different ways. A user object may have multiple UPN's but only one can be used to log on to the domain with. It's up to the sysadmin to select which of the alternate UPN's a user will use if multiple UPN's exist and an alternate UPN is desired as the "default" UPN. The UPN that is created at the time of domain creation is the default UPN and needs to be manually changed per user if additional UPN's are created and one of the alternate UPN's is desired to be the UPN for user logon. Multiple UPN's don't allow for logging on as any of the available UPN's, only the one that's selected on the account tab of the AD user object properties.

A UPN may not be a required attribute, but it's always created anyway, as a UPN matching the AD domain name is created at the time of domain creation.

share|improve this answer
    
The UPN is a DN for a user object. You can have more than one UPN Suffix (FQDN) in a domain, and assign various users to each, but each user has to be assigned to just one. More info: support.microsoft.com/kb/243280/EN-US –  Chris S Jul 28 '10 at 17:24
    
Which is my point exactly. The OP can create a UPN of abc.co and each user could then log on to the domain as username@abc.co. –  joeqwerty Jul 28 '10 at 17:41
    
I think you're misunderstanding what a UPN is. UPN = RDN + FQDN. –  Chris S Jul 28 '10 at 20:40
    
@Chris S: UPN = Account Name + UPN Suffix - The domain's name has no effect on the forest-wide UPN suffixes that are configured. –  Evan Anderson Jul 28 '10 at 20:44
    
@Evan, Microsoft's term for the LDAP concept is "UPN Suffix", but otherwise you're correct. –  Chris S Jul 28 '10 at 20:55

Your Answer

 
discard

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