Do you get this SSO configuration error: “ A Single Sign-on error has occurred. Please contact an administrator. Details: Could not find domain controller ” ?

When you try to configure SSO in MOSS, it may fail with an error like this one:

 If you check ULS log, you may find these entries about the issue:

 In the application Event Log on the SharePoint Web Server, you may find this log entry:

 Event Type: Error

Event Source: Office SharePoint Server

Event Category: SSO

Event ID: 6517

Date: 2/21/2008

Time: 9:55:12 AM

User: N/A

Computer: MOSSBOX

Description:

User CONTOSO\SSO failed to configure the single sign-on server. The error returned was 0x80070995. Verify this account has sufficient permissions and try again.

It sounds like the SSO service account contoso\SSO seems to have permissions, huh? Here are the troubleshooting tips for the issue:

Variables:  

Let us consider the following details (variables :) ) for this issue scenario:

Farm service account: contoso\SPSVC

SSO administrator account: contoso\SSO

FQDN name of the SharePoint server: MOSSBOX.contoso.com

Step 1: Confirm SSO accounts are set with correct permissions

As mentioned in Plan for single sign-on (https://technet.microsoft.com/en-us/library/cc262305(office.12).aspx#section4) , make sure the SSO accounts are set with correct permissions / privileges. It is one of the important steps for the troubleshooting of the issue.

Step 2: Confirm whether the name resolution works correctly

Let us find out the current logged on Domain information using the command: Set U

From command line, type: set u

The result may be something like this:

USERDNSDOMAIN=CONTOSO.COM
USERDOMAIN=CONTOSO
USERNAME=SPSVC
USERPROFILE=C:\Documents and Settings\SPSVC

Now let us find the logged on domain controller information using the command: Set L

From command line, type: set l

The result may be something like this:

LOGONSERVER=\\DC1

At this stage, let us find out the PDC emulator role holder in the domain using the command: netdom

From command line, type: netdom query fsmo

The result may be something like this:

Schema owner Box1.CONTOSO.com
Domain role owner Box1.CONTOSO.com
PDC role DC1.CONTOSO.com
RID pool manager Box3.CONTOSO.com
Infrastructure owner Box3.CONTOSO.com
The command completed successfully.

According to the above command line, the PDC emulator role is set with DC1.CONTOSO.com

That said, let us use the command nltest which uses DNS queries to resolve the PDC emulator in the same way that  any application would resolve.

From command line, type: nltest /dcname:contoso

You may get a result something like this:

NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound

Don't you think this is the same error message we see in the ULS log? Yes, that's correct.  If so, what is the expected result for the above command ?  It should be something like this:

PDC for Domain svc is \\DC1
The command completed successfully

Q: What does the above error mean? 

A: The nltest reslt indicates that DNS queries to find/resolve the  PDC emulator failed - which is a DNS name resolution issue AND not an issue related to user permissions!

That said, let us verify whether this is really a DNS name resolution issue using nslookup command:

From command line, type: nslookup

The result may be something like this:

Default Server: DC1.contoso.com
Address: 10.0.0.10

Now let us change the context to Service Location record - type this command in nslookup

> set type=srv

The above line won't produce any result and it would return the > prompt

Now let us find the SRV record for the PDC emulator by typing _ldap._tcp.pdc._msdcs.CONTOSO.com

> _ldap._tcp.pdc._msdcs.CONTOSO.com

You may get a result like this:

Server: DC1.contoso.com
Address: 10.0.0.10

_ldap._tcp.pdc._msdcs.CONTOSO.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = DC1.CONTOSO.com
DC1.CONTOSO.com internet address = 10.0.0.10

Q: What does the above result mean?

A:

• DC1.CONTOSO.COM is the PDC emulator as well as the DNS server for the domain.
• Also we get same results for "SET L" + Netdom + nslookup which confirms that the issue is NOT about the DNS name resolution EVEN THOUGH we get error for NLTEST command.
• If the above result does not result correct PDC name, then there are certainly issues at DNS side

As we confirmed the working of name resolution here, we need to proceed with the checking of firewall ports (necessary for SSO) that are opened  [Step 3 covers the relevant details]

Are there multiple DNS servers in your environment?

There are possibilities that there may be one or more forest level DNS servers available in addition to the domain level DNS in the environment - here is a sample output on that aspect:

when we execute _ldap._tcp.pdc._msdcs.CONTOSO.com:

Server: ForestDNS1.CONTOSOFOREST.com
Address: 10.0.0.20

_ldap._tcp.pdc._msdcs.CONTOSO.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = DC2.contoso.com
DC2.contoso.com internet address = 10.0.0.21

According to the above o/p, the PDC emulator is  DC2.contosoforest.com which is different from the output for "netdom query fsmo" command! This kind of situation may occur if CONTOSOFOREST.com is a forest where contoso.com is one of the domain trees.

That said, let us query the domain's own DNS server using NSLOOKUP:

Enter this command in NSLOOKUP:

> server DC1.contoso.com

This changed the DNS  context and the result may be something like this one:

Default Server: DC1.contoso.com
Address: 10.0.0.10

Now set the context to Service Location record
> set type=srv

To find the SRV record for the PDC emulator, let us type _ldap._tcp.pdc._msdcs.contoso.com

> _ldap._tcp.pdc._msdcs.contoso.com

Server: DC1.contoso.com
Address: 10.0.0.10
_ldap._tcp.pdc._msdcs.contoso.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = DC1.contoso.com

DC1.contoso.com internet address = 10.0.0.10

With the above output, it is clear that:

• DC1.contoso.com is the correct PDC emulator for the domain
• In order to get the correct PDC emulator name, the correct DNS server for the domain (in this case, the same box DC1) should be set for the IP configuration of the SharePoint box.

A member server of the domain should always point to it's own domain's domain controller for DNS & the Domain's Domain Controller should have forwarders to query the rest of the forest.

That said, let us verify the results for the command ipconfig:

From command line, type: ipconfig /all

You may get an o/p like this:

Windows IP Configuration
Host Name . . . . . . . . . . . . : MOSSBOX
Primary Dns Suffix . . . . . . . : contoso.com
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : contoso.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : contosoforest.com
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #3
Physical Address. . . . . . . . . : 00-10-56-84-32-40
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.0.0.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.0.254
DNS Servers . . . . . . . . . . . : 10.0.0.21

With the about o/p, it is quite clear that 10.0.0.21 is NOT the correct DNS server for the box (which resolves to the Forest level DNS rather than the domain level DNS)

That said, we need to modify the IP settings for the adaptor to reflect 10.0.0.10 as the primary DNS server - with that if you execute nslookup, then you would be able to get the correct PDC name.

Step 3: Enable necessary Ports 

The next part of the troubleshooting of the issue involves the checking of ports in the PDC. For that we can use TELNET from our MOSS box [we need to enable TELNET feature if you are using MOSS with Windows 2008]

• According to Plan security hardening for server roles within a server farm (Office SharePoint Server) ( https://technet.microsoft.com/en-us/library/cc262849(office.12).aspx#section5 ), confirm whether we have necessary ports opened in the domain controller as well as in the SharePoint boxes.
• Make sure the OS specific firewall ports are correctly configured
• Also make sure your IPSec rules (if implemented) and firewall ports are correctly configured.

For example, if you do not get connected to port 135 by using TELNET DC1 135, then you are expected to get only the error "NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound" for nlstat command as well as SSO configuration cannot complete.

You can use PortQueryUI (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=8355e537-1ea6-4569-aabb-f248f4bd91d0&displaylang=en) in addition with PortQuery (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=89811747-C74B-4638-A2D5-AC828BDC6983) to check the ports opened in the servers.

Step 4: Further troubleshooting

If the issue still persists, gather simultaneous network traces from both the SharePoint box (The first server computer on which the Single Sign-On service is enabled) and the domain controller that is resulted as part of running set l command.

Check the associated traffic to identify the possibilities for the issue.  In case if you require further assistance in troubleshooting, kindly create a support case with Microsoft Support.

Hope this post would be helpful!