Tech Blog

So a while back we had  quite a setup issue with Lync 2010 where two users couldn’t connect at a remote site couldn’t connect to Lync 2010, the setup:

Two Domains:

Domain one (BohemianGrove.co.uk): Contains the Lync and Exchange Servers also the Linked mailboxes (disabled),

Domain two (Corp.co.uk): Contains the users who connect to Outlook and Lync via linked mailboxes (we use the SID Mapping Tool to map the SID of a disabled user account).

External: connects via an edge server which works great.

The two users who can’t connect are getting the error:

 "cannot sign in because the server is temporarily unavailable"

So to trouble shoot I installed Snooper on the Lync 2010 server, which is a tool to debug connection issues.  The results were thus:

$$begin_record
LogType: diagnostic
Severity: error
Text: The authentication authority is unavailable. Check connectivity to the KDC (Kerberos) or Domain Controller (NTLM).
Result-Code: 0xc3e93ec9 SIP_E_AUTH_AUTHORITYUNAVAILABLE
SIP-Start-Line: REGISTER sip:DOMAIN1.com SIP/2.0

_______

$$begin_record
LogType: security
Text: Failed to validate user credentials
Result-Code: 0x80090311
SIP-Start-Line: REGISTER sip:DOMAIN1.com SIP/2.0

Well that’s odd as everyone else can authenticate without issue, so I replicated the users and tried to connect from the same site and ran into exactly the same issue.  Very odd.

I ran NSLOOKUP produces:

 nslookup
Default Server:  dc10.Corp.co.uk
Address:  192.168.100.10

> set type=srv
> _sipinternaltls._tcp.corp.co.uk
Server:  dc10.corp.co.uk
Address:  192.168.100.10

Non-authoritative answer:

_sipinternaltls._tcp.corp.co.uk  SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = lyc01.BohemianGrove.co.uk

Well that looks fine. So at this point I was stuck.

So after some thought I decided to track the logon process via our firewalls, i.e. what does the client do when it tries to connect.  Note – you could do this with wire shark or similar.

Well what was interesting here was the client on the Corp.co.uk domain was connecting to the Lync server on the BohemianGrove.co.uk domain without issue but when the Lync 2010 server tried to authenticate the user on the Corp.co.uk domain it was referencing a domain controller hundreds of miles away that clearly seemed to have some issues with DNS and site connections hence the authentication problems.

Great I though, I’ll sort out the authentication and we should be good to go!!

Well no not quite, when a server tried to authenticate against another domain, Windows finds the closest domain controller by using DNS and SRV resource records, if these records are not correct or incorrectly configured the returning authentication server could be potentially any domain controller in the Corp.co.uk domain.  So how do we fix this?

Well firstly, make sure DNS is up to scratch.  In my case I made full use of Active Directory Conditional Forwarders i.e. set up a conditional forwarder that says – if you receive any requests for corp.co.uk then forward them to this IP and vice versa.

Secondly and this is important too, rename the sites in Active Directory Sites and Services in both domains so they match this will allow DNS responses across domains and hence authentication to take place on the correct Domain Controller.

Lastly I rebooted Lync and the servers and the everything worked as it should!!

Here’s the article I gathered most of my information from, its brilliant: http://blogs.technet.com/b/askds/archive/2008/09/24/domain-locator-across-a-forest-trust.aspx