[Authentication] Delay in update of AD msDS-KeyVersionNumber after computer password change via "adcli join"

Fri Dec 18 11:44:28 PST 2015

Hello Stef,

Honestly, I feel this is an error on the AD side. Perhaps due to my limited knowledge of AD and the way I would expect something like this to work. 

What makes me hesitant with that approach is the fact that we appear to be having an issue on a fresh join as well. So what that means, for us anyway, is we'd need checks at every action before proceeding. If it were just the password change part, I think the idea would set a little better with me.

Having said that, who knows, perhaps it might not be a bad idea to account for oddities like this in AD environments. If you feel the check/retry polling is the way to go, rather than an option to the join though, perhaps it could happen naturally when it observes the kvno number did not increment.  If any tunable option, perhaps the re-try interval?

-Chris

-----Original Message-----
From: Authentication [mailto:authentication-bounces at lists.freedesktop.org] On Behalf Of Stef Walter
Sent: Friday, December 18, 2015 11:33 AM
To: Cross-desktop authentication and single sign-on
Subject: Re: [Authentication] Delay in update of AD msDS-KeyVersionNumber after computer password change via "adcli join"

On 18.12.2015 17:27, Chris Rutledge wrote:
> Hello Stef,
> 
> That case was one of the first documented issues we came across at the 
> beginning of this which looked like a match to our issue. I went back 
> to that same issue yesterday and upon seeing that a change had been 
> checked in for it, I did a git clone.
> 
> It did not help in our case.

I guess i should have read your email better.

In your opinion, do you think adcli may need to have a join option to poll the DC until the "right" kvno shows up? The current code assumes that the kvno has incremented ... which it will ... but we may have to wait for that to happen.

Stef

> -Chris
> 
> -----Original Message----- From: Authentication 
> [mailto:authentication-bounces at lists.freedesktop.org] On Behalf Of 
> Stef Walter Sent: Friday, December 18, 2015 11:02 AM To:
> Cross-desktop authentication and single sign-on Subject: Re:
> [Authentication] Delay in update of AD msDS-KeyVersionNumber after 
> computer password change via "adcli join"
> 
> On 18.12.2015 16:15, Chris Rutledge wrote:
>> Hello,
>> 
>> 
>> 
>> About 2 months ago we started having issues when using adcli to join 
>> our Windows AD domain. The symptom we first noticed was not being 
>> able to log into our stateless HPC compute nodes and messages in the 
>> logs stating the kvno was mismatched.
>> 
>> 
>> 
>> As our compute cluster nodes are stateless, every time they are 
>> rebooted, they rejoin the domain upon boot via "adcli join".
>> Historically this has worked great. We did discovered we could work  
>> around the issue by repeating the adcli join command until we finally 
>> received the latest kvno. The number of attempts would vary from node 
>> to node – timing and luck I suspect.
>> 
>> 
>> 
>> Yesterday, I decided to download the latest version of adcli from 
>> GitHub to debug.
>> 
>> 
>> 
>> Here is what I have found:
>> 
>> 
>> 
>> 1)      The adcli command is confirmed to connect to any one of the
>> 3 domain controllers and stay connected to that server throughout the 
>> session.
>> 
>> 2)      With unmodified versions of adcli, there was a very large
>> chance we would get the old kvno value after the password change.
>> 
>> a.       We could see the server we are talking to does not yet
>> have this changed value by observing the msDS-KeyVersionNumber via  
>> ldapsearch against all 3 DCs.
>> 
>> 3)      Not until I entered a sleep(30) statement in adcli after
>> the password update and before we retrieve the new kvno did things 
>> start to work reliably.
>> 
>> 
>> 
>> I would understand the need to sleep if adcli would attempt to 
>> retrieve the updated kvno value from any one of the 3 DCs. However, 
>> it is my understanding that there is code in there to make sure we 
>> talk to only the one and the expectation is once the password change 
>> has been made the kvno value should reflect this – immediately.
>> 
>> 
>> 
>> Also, if we delete the computer object from the domain we get an 
>> error the first time we attempt to join setting the password. I 
>> suspect the same timing issue here…the computer object does not exist 
>> yet on this server.
>> 
>> 
>> 
>> Based on my testing and observations, this smells like a performance 
>> or configuration issue on the Windows AD side. Others are not so 
>> convinced of this and think that perhaps adcli should delay between 
>> operations for replication to complete.
>> 
>> 
>> 
>> So I figured I would ask the experts, should adcli delay this 
>> retrieval of the new kvno or are we looking at an AD issues? If you  
>> too suspect an issue with AD, any idea where to begin?
> 
> Does adcli 0.8.0 fix the issue?
> 
> http://lists.freedesktop.org/archives/authentication/2015-December/000
> 321.html
>
>  It's pretty new, but if you have a chance to try it out. In
> particular:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=91185
> 
> Similar case seems to be described here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=91185#c4
> 
> Stef _______________________________________________ Authentication 
> mailing list Authentication at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/authentication
> _______________________________________________ Authentication mailing 
> list Authentication at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/authentication
> 

_______________________________________________
Authentication mailing list
Authentication at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/authentication