ADFS 2.0 Question about UPNs
I have a question about setting up UPN for ADFS. We typically have used the .local domain name for joining machines. If we want to use a routable domain we have to use a non .local domain. My understanding is each user needs their UPN changed as well? I have added this UPN to the domain. However, when I change it for a user they can no longer logon to the .local domain. The only way to logon now is to use user@newdomain.com for the username. So is this required? Is the solution to tell users to use this as their username in the future or re-join everything to the .com public routable domain? Thanks!
April 29th, 2011 10:53am

Hello, please descibe what you mean with routable domain. If i understand you correct you have a DOMAIN.LOCAL installed and now will have another domain newdomain.com to connect with AD FS to?Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
May 1st, 2011 7:28am

Hi, I would like to confirm what is the current situation? Would you please clarify the questions Meinolf Weber asked? If there is anything that I can do for you, please do not hesitate to let me know, and I will be happy to help. Regards, Arthur Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com .Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
May 5th, 2011 4:05am

I have a similar problem. Right now I have a DOMAIN.LOCAL domain and a DOMAIN.COM domain. All of my users are on the .local domain and I need to set up a CRM system accessible from the outside with a DOMAIN.COM name. There is a trust between the DOMAIN.LOCAL and DOMAIN.COM domains but they are in separate forests. I guess my question is if you can have ADFS set up with a DOMAIN.LOCAL name and somehow give it a name for people coming from the outside.
Free Windows Admin Tool Kit Click here and download it now
May 6th, 2011 12:08pm

Well I'm using ADFS 2.0 to connect with Office 365. I have added another domain.com UPN and have changed certain users to use that new UPN. I'm just not sure what needs done to move to using a public .com domain. We do have ADFS working with Office 365 but I don't think its the recommended way. For instance, the ADFS server is joined to the .local domain but everyone will logon using their new domain.com UPN. Is it important to have all the computers joined to the .com domain? Or is it okay to have them joined to the .local domain? We don't have any of the AD/DNS stuff really setup for the domain.com domain. We currently use an external service to host the dns for the domain.com domain. Thanks!
May 11th, 2011 1:52pm

Answer to the question posed by th3j35t3r ============== What you are asking is not possible due to your current configuration. You cannot have two domains with the same UPN's (User Principal Name) contained in them unless they are in the same forest. This is because of name suffix routing works across trusts. Please reference the technet article below in this regard Answer to the question posted by philjfry ============== The UPN (User Principal Name) has nothing to do with the domain name. You do not need to rename or rejoin any users or computers. UPN's are used for kerberos authentication. When a user login occurs the the login information goes to the KDC which does an LDAP search in its own domain for that user principal name. if it cannot find the UPN locally it will search the global catalog. If the UPN is found in the global catalog it is routed to the proper KDC or if not it will be sent to the TDO (trusted domain object) that matches the name suffix routing for that name suffix under the active directory trust configuration. Please see the following in regard to Routing name suffixes across forests - http://technet.microsoft.com/en-us/library/cc784334%28WS.10%29.aspx The only issue I can foresee you running into is if one of the users cached credentials happens to be the users alternate User Principal Name value when an attempt is made to use Kerberos Authentication it has the potential to use the UPN format of the users account name. Since the value of UPN stored in the cached credential is not the same as the value stored in Active Directory Kerberos authentication will fail. Resolution For Vista or higher clients computers: 1. With the comptuer on the corporate network have the user logon to the workstation. 2. With the users workstation connected to the corporate network (either directly or through VPN) have the user lock their workstation and unlock it. For Windows XP / Windows Server 2003 computers: 1. With the comptuer on the corporate network have the user logon to the workstation using their UPN name. for example: bob@contoso.com 2. With the users workstation connected to the corporate network (either directly or through VPN) have the user lock their workstation and unlock using their UPN name. for example: bob@contoso.com 3. With the users workstation connected to the corporate network (either directly or through VPN) have the user open a command prompt and attempt to launch an application using runas.exe using the users UPN. for example: runas /user bob@contoso.com "cmd /c echo account updated!"Ketan Thakkar | Microsoft Online Community Support
Free Windows Admin Tool Kit Click here and download it now
May 17th, 2011 1:39am

@philjfry: Fascinating... I've been trying to get Office 365 AD FS integration working, and continually get Event 364 errors regarding the PassiveEndpointAbsolutePath. Did you ever run into that when you were setting up your configuration (which is VERY similar to what I'm working with here). (I'm trying to have this run on a single publicly accessible server, horrible security, but budgets are budgets..., but it's a single ".local" domain with a .com UPN associated with it.) Office365 help has been trying their hardest to figure out what might be wrong, but we're all pretty much stuck.
June 8th, 2011 12:32pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics