[Samba] Authentication to Secondary Domain Controller initially fails when PDC is offline

[James]

Comments inline

On 1/5/2016 6:30 AM, Ole Traupe wrote:
>
>>
>>     I can't recall but are you able to get a packet trace? This may 
>> help further troubleshoot.
>
> I'll look into this. However, Rowland stated that bind9 will be the 
> only solution.
I'm not sure this is 100% correct. I just did a packet trace and I do 
not see any NS or SOA records being requested during authentication. 
This is only from a Windows 7 workstation. I do not have a test member 
server setup to test it's behavior.
>
>
>>
>> Just to recap you do you both servers listed as available DNS servers 
>> on your workstations? As well as your member server? 
>
> Yes, of course. For member servers, this is the content of 
> /etc/resolv.conf:
>
> search my.domain.tld
> nameserver IP_of_1st_DC
> nameserver IP_of_2nd_DC
>
>
>> I made a small tweak but haven't fully tested is adding the following 
>> options to my resolv.conf.
>>
>> cat /etc/resolvconf/resolv.conf.d/tail
>> options timeout:1
>
> Great, this sounds exactly as what I need! However, I tried this: no 
> effect. I created this file and restarted the network service. But I 
> still get long timeouts and can't login via ssh, when I suspend my 1st 
> DC.

I assume you are only testing against your member server?

>
> # cat /etc/resolvconf/resolv.conf.d/tail
> options timeout:1
> options edns0
>
> Or do I need Network Manager for that?
No.
>
>
>> options edns0
>
> What's that for, particularly?
In short read below. For more details read the RFC 2671

"The Domain Name System's wire protocol includes a number of fixed 
fields whose range has been or soon will be exhausted and does not allow 
clients to advertise their capabilities to servers"


>
>
>>
>> timeout:n
>>                      sets the amount of time the resolver will wait 
>> for a response from a remote name server before retrying the query  
>> via  a  different  name
>>                      server.  Measured in seconds, the default is 
>> RES_TIMEOUT (currently 5, see <resolv.h>).  The value for this option 
>> is silently capped to 30.
>>
>> edns0 (since glibc 2.6)
>>                      sets RES_USE_EDNSO in _res.options.  This 
>> enables support for the DNS extensions described in RFC 2671.
>>
>> From what I researched, this is the intended behavior on a Microsoft 
>> Server. Again I can disable my "PDC" and log in from a windows 
>> workstation just fine. It appears for some users after a hour or so 
>> they run into issues 
>
> I thought this was only happening with roaming machines resulting in 
> cached logins.
>
>
>
Windows will cache kerberos information. Below is a brief printout from 
my packet trace.

172.16.232.30    172.16.232.39    TCP    66    56275→88 [SYN] Seq=0 
Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

You can see above that my workstation(172.16.232.30) is trying to access 
the server on port 88( I took the server down). It doesn't matter what 
you have in your DNS settings. It will pull from the cache if you have 
already authenticated prior. I removed the DNS 172.16.232.39 from my 
workstation and it still attempted to contact this IP. Less then a 
second it will give up and use DNS to find another DC to contact.

172.16.232.30    172.16.232.29    DNS    126    Standard query 0x39dd  
SRV _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.local
172.16.232.29    172.16.232.30    DNS    178    Standard query response 
0x39dd  SRV 0 100 88 dc1.domain.local SRV 0 100 88 dc2.domain.local
172.16.232.30    172.16.232.29    DNS    76    Standard query 0x1ccb  A 
dc1.domain.local
172.16.232.29    172.16.232.30    DNS    92    Standard query response 
0x1ccb  A 172.16.232.29
172.16.232.30    172.16.232.29    CLDAP    210    searchRequest(250) 
"<ROOT>" baseObject
172.16.232.29    172.16.232.30    CLDAP    180 searchResEntry(250) 
"<ROOT>" searchResDone(250) success  [1 result]

Above you see my workstation used it's next configured DNS 
IP(172.16.232.29) to contact another DC that it could authenticate 
against. Once it receives these records and responses it moves onto the 
3 way handshake and transmitting of the TGT.

Now I took down my "backup" DC in this instance. But the same rules 
should still apply.



-- 
-James