Custom attribute in AD behaves as if cached in AD AAA

We've added a custom attribute to Active Directory.

 

We've added a process that sets this attribute to an APM policy via a web API.

 

When the user logs in and it is not set (via Active Directory AAA lookup), we set a value.

 

If the user logs out and in again quickly after this, the new session behaves as if the custom attribute is still not set, when it should be set, and if the user waits a few seconds it all works.

 

I believe (I could be wrong, somethings not right) that the F5 and the web API server are using the same Active Directory server, so I don't believe this is a propagation delay in Active Directory between AD servers.

 

We don't see this behaviour with the password attribute.

 

Is there some caching going on here, or some property of the password attribute that avoids caching either in the F5 APM or AD?

 

The Active Directory AAA has a lot of cache properties, but none of them looked relevant from the documentation.

 

Its a minor issue in the scheme of things but when it happens it is confusing for the end user.