Kerberos Auth Help Needed

RobertKaucher

Ok, I have a Kerberos issue, before I get intot he details let me explain this did work at one time. Within the past 3 weeks it has failed.

We have an odd arangement. All employess work in the AM domain of parent.net. There is another forest/domain linked via trust to am.parent.net called ChildCompany.net. This is the IT sandbox for our department. All of our servers exist in ChildCompany.net which is in a different forest.

Forest: parent.net
Domain: am.parent.net

Forest: ChildCompany.net
Domain: ChildCompany.net
SPNs are configured for the services correctly.

Users from am.parent.net are unable to authenticate via Kerberos to my SharePoint server in the ChildCompany.net domain. Users from the ChildCompany domain are authenticated using Kerberos *even when* surfing the Sharepoint site from an am.parent.net machine. So I logged in as rkaucher@ChildCompany.net to my PC rkauch-win7.am.parent.net and was able to surf SharePoint and received a Kerberos ticket.

Any ideas? We have rebooted the DCs in childcompany.net.

Everyone

What is the domain level? Have any 2008 DC's been introduced recently?

RobertKaucher

Everyone wrote: »

What is the domain level? Have any 2008 DC's been introduced recently?

ChildCompany.net is Server 2003 forrest and domain and we have a 2008 DC and a 2008 R2 DC. Our PDC (it's the only physical and holds all FSMO roles) is Server 2003 R2. I am suspecting the issue is in the am.parent.net domain.

EDIT: These are not new. All DCs have existed for more than 6 months.

Claymoore

Are the users being prompted for a username/password or are they just being flat-out denied?

RobertKaucher

Claymoore wrote: »

Are the users being prompted for a username/password or are they just being flat-out denied?

Sorry, they are negotiating down to NTLM. I can only imagine there must be something wrong with the trust.

Devilsbane

RobertKaucher wrote: »

Sorry, they are negotiating down to NTLM. I can only imagine there must be something wrong with the trust.

Thats the first thing that I was thinking. Wouldn't know where to begin with it though.

RobertKaucher

Devilsbane wrote: »

Thats the first thing that I was thinking. Wouldn't know where to begin with it though.

What sucks is that this requires interaction with the parent company's admins and I always feel like I am a constant burden to them.

RobertKaucher

Here is what changed:
Control of the the .com DNS zone was granted to my group and one of the other members recreated the records. He, properly I might add, recreated the .com entry for the SharePoint site as an A Name. Previously it had been a C Name (which is when the setup was working).
I changed the entry back to a C Name and like magic everything started working again.

The Topology
Before I get into how I resolved this I am going to summarize the topology again. There are two AD forests connected by a 2 way transative trust. Both are Server 2003 functional level. Most user accounts are in the parent.net forest, specifically am.parent.net domain). The SharePoint resource is in the child.net forst, single domain. The name we wish to use for the SharePoint deployment is portal.child.com - not portal.child.net. child.com is an AD integrated zone hosted internally by the child.net domain controllers. Forwarders exist in the parent.net DNS servers for child.net and child.com.

The Problem
Kerberos authentication was not working for user accounts in the parent.net forest. Kerberos authentication was working for accounts in the child.net forest. WireShark captured revealed KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN errors. Because the C Name record had been destroyed and replaced by an A Name the parent.net domain controllers were unable to determine who the principal name HTTP/portal.child.com belonged to and thus returned the Kerberos error.

Here is what needs to be done to make things function correctly:
In AD Domains and Trusts a UPN Suffix entry needs to be created for the .com domain in the resource domain. You right click Active Directory Domains and Trusts node in the MMC and select properties to get to the UPN Suffixes dialog.
IN AD Domain and Trusts a Name Suffix Routing entry needs to be created/enabled on the trust in the user domain (parent.net).
1. Open Active Directory Domains and Trusts
2. Right click the root domain and select properties.
3. Click the Trusts tab
4. Under the "Domains trusted by this domain" select the resource domain (child.net in the example)
5. Click properties.
6. Click the Name Suffix Routing tab.

What you do next depends on the version of the MMC you are using. For a 2008/Win 7 resource kit snapin you might have to click "refresh" and then enable routing for child.com. For a 2003 MMC you might just need to enable routing for child.com.

Devilsbane

RobertKaucher wrote: »

Here is what changed:
Control of the the .com DNS zone was granted to my group and one of the other members recreated the records. He, properly I might add, recreated the .com entry for the SharePoint site as an A Name.

For all of your future enhancements, let me introduce you to troubleshooting 101.

http://www.snidelyworld.com/Humor/ProblemSolve.pdf

RobertKaucher

Well, on the bright side I can now say that I know more about the workings of Kerberos and Constrained Delegation in an AD environment than anyone else I know - which really may not be saying much. But there you have it.