Show original LAPS password expiry date.

[wakco]

A problem that happens more often than anyone would like is LAPS changing a password around the time we look at it with Access Manager. I believe it would be useful to know what the existing/previous expiry date/time is, as well as the new date/time that Access Manager changes it to.

Showing the existing date on one of the attached screens would help an admin to know it might change again while they are using it, perhaps even high lighting the previous expiry date if it is today, or already past.

[ryannewington]

Hey @wakco

It sounds like something else is in play here. The time between reading the LAPS password from the directory and stamping the new expiry date is... milliseconds at most. For a race condition to exist, the LAPS agent would have had to rotate the password within those milliseconds. It's highly unlikely to be the cause of what you are seeing.

Can you describe in a bit more detail what you see happening in your environment. What does your site topology look like in respect to the location of the AMS server, its closest DC, and the clients you are having problems with? I'm wondering if we could we be looking at an AD replication issue?

[wakco]

I'm afraid I do not know enough about our setup, but essentially Active Directory across 4 Domain Controllers, with one Access Manager server all in the same server room (I think) handling over 4000 computers (Windows and macOS) bound to AD and running LAPS (or macosLAPS) across a University campus network, quite simply your milli-seconds is a dream world, totally unrealistic, also you have the timing backwards, Access Manager would have to look at the password after LAPS did, but before Laps updates Active Directory, to which this can be second, or under the right conditions, minutes, due to network and processing lag on the computer whose admin password is being changed.

Here's a quick log of macosLAPS on an Apple Silicon M1 Pro processor taking 3 seconds to process...

Info|2022-09-09 14:04:07|macOSLAPS|Password Change is required as the LAPS password for admin, has expired
Info|2022-09-09 14:04:07|macOSLAPS|The local admin: uowadmin has been detected to have a secureToken. Performing secure password change...
Info|2022-09-09 14:04:07|macOSLAPS|Performing password change using stored keychain item.
Info|2022-09-09 14:04:10|macOSLAPS|Password change has been completed locally. Performing changes to Active Directory
Info|2022-09-09 14:04:10|macOSLAPS|Password change has been written to Active Directory for the local administrator uowadmin. The new expiration date is 2022-10-09 14:04:07
Info|2022-09-09 14:04:10|macOSLAPS|Keychain does not currently exist. This may be due to the fact that the user account has never been logged into and is only used for elevation...

I should also point out, that myself and several of my co-workers have experienced the issue first hand.

Lastly, we have LAPS on both OS'es set for monthly change, and running at there versions default timings for checking and updating.

[ryannewington]

@wakco I don't doubt you are experiencing an issue, and we're more than happy to help troubleshoot this with you, but I don't think a race condition is the cause. Even with the agent's 3 second delay, on a monthly change, the chance of a race condition here is extremely unlikely. Even if it was a 10 second or 30 second delay. Having it happen to one person would be unlucky, but with multiple people experiencing it - there has to be something else at play.

Are you able to obtain and share agent and AMS server logs at the next time this happens?

[wakco]

I do not have access to that system. The focus does appear to be on trying to solve the race condition (which is impossible, or to put it another way, only possible if AMS, AD, and LAPS are all running on the same host whose LAPS password is being looked up), when all I'm asking is for AMS to provide a basic warning that the software could easily do, and would enable all AMS users to realise that perhaps they should re-check the password either when it doesn't work or if close enough to when it is checked, immediately.

But this might better help in understanding the problem, there are 4 AD servers, therefore some replication is going on, which of course means that the one AMS might look at might also be different to the one that is updated by LAPS from the computer being looked up.

To be clear tho, I'm not asking for AMS to solve the race condition, I'm asking for AMS to simply display the old expiry date.

[ryannewington]

Hi @wakco

Your ask is to provide a software solution for a symptom, not the cause of the problem. Ideally, we'd solve the root cause of the problem - it's something that shouldn't be happening at all. AMS is used on hundreds of thousands of machines around the world, and this isn't happening en mass. There's some unique combination of events going on here which is surfacing this issue for you. I'm not ruling out a bug in AMS, but we don't see the answer to the problem as modifying the UI in the way you described.

If you'd like us to assist with trying to troubleshooting what is actually happening here, we are more happy to do that with you. It will involve collecting and analyzing the log files previously mentioned, and perhaps some AD replication troubleshooting. However, I do understand that's not be the outcome you were after from this ticket, and that is fine if you don't want to proceed.

[wakco]

Yes, I am asking AMS "... to provide a software solution for a symptom, not the cause of the problem." A problem I know is impossible to fix, which is why I'm not asking you to waste time trying to fix the problem, I'm asking for an indicator for admins to know they might have a problem.

[ryannewington]

Hi @wakco

Unfortunately, we won't be making that change. I'll close this request for now. If you do decide you'd like assistance with troubleshooting the problem in future, please don't hesitate to reach out.