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:
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"
$$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
_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