ADFS requires third party certificate. This means you have to find a trusted provider to issue the certificate. You won't get that for .int or .local. ASB's suggestion of using a COMPLETELY DIFFERENT domain (but still one you own), is completely valid.
In re: ADFS, from the ADFS deployment whitepaper: Trusted certification authorities Because both TLS/SSL and token signing rely on digital certificates, certification authorities (CAs) are an important part of ADFS. Public CAs, such as VeriSign, Inc., represent a mutually trusted third party that allows the identity of the bearer of a certificate to be identified. You can use enterprise CAs, such as Microsoft Certificate Services, for providing token signing and other internal certificate services. If a client is presented with a server's authentication certificate, the client computer verifies that the CA that issued the certificate is in the client's list of trusted CAs and that the CA has not revoked that certificate. This verification ensures that the client has reached the intended server. When a certificate is used for verifying signed tokens, the client uses the certificate to verify that the token was issued by the correct federation server and that the token has not been tampered with. UPN claim When you configure the resource partner, you can specify whether a UPN claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified outgoing suffix. For example, [email protected] can be mapped to [email protected]. Note that only one outgoing suffix may be specified. E-mail claim When you configure the resource partner, you can specify whether an e-mail claim is to be sent to the resource partner. You can also specify a suffix mapping so that any suffix is mapped into a specified suffix. For example, [email protected] can be mapped to [email protected]. Note that only one outgoing suffix may be specified. Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Joseph Heaton [mailto:[email protected]] Sent: Wednesday, April 28, 2010 3:57 PM To: NT System Admin Issues Subject: Re: Current AD domain naming best practices I'm simply gathering information on the 3 options, and what everyone recommends. Unfortunately, there is no clear-cut "winner". I've found that all 3 are valid options, depending on how much administrative overhead you want to add to the process. However, Michael Smith brought up a rather strong concern over why different names would be bad, if you're possibly going to implement ADFS. Anyway, I very much appreciate your, and everyone's, input. Joe >>> "Andrew S. Baker" <[email protected]> 4/28/2010 12:33 PM >>> A subdomain is fine, but suffers many of the same drawbacks as using a single DNS namespace. And you're involving more DNS servers into the resolution process for what purpose again? -ASB: http://XeeSM.com/AndrewBaker Sent from my Motorola Droid On Apr 28, 2010 12:51 PM, "Joseph Heaton" <[email protected]> wrote: Andrew, So you don't recommend the subdomain? Also, if you could expand on your answer, it'd be great, as I'm bringing all ideas to a meeting this afternoon, with pros/cons behind each option. >>> "Andrew S. Baker" <[email protected]> 4/28/2010 8:55 AM >>> Use two separate domain names, even if you register the internal one. You can avoid all manner of p... the Novell guy is saying. Is that still true today? We are on private IPs internally, so external forces can't route to the inside an... ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
