Hi,
So the situation is when the user is Enabled in the cache but disabled in MSAD. When you
attempt a login with a password Grant it returns Invalid Credentials. I would expect this
to return Account Disabled. Extended LDAP diagnostic messages should provide this
information, certainly against MSAD anyway.
This is also different behaviour to when you use the refresh token grant. If the user is
Enabled in the cache but disabled in AD the token request returns Account Disabled. This
is the expected behaviour.
The cache would naturally update and you get the right message at login (password grant),
but only once the sync has occurred. We want to try and avoid resyncing too often, but
still get the correct error messages.
Regards
Mark
Sent from
Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
________________________________
From: Marek Posolda <mposolda(a)redhat.com>
Sent: Thursday, August 9, 2018 8:57:33 AM
To: Mark Hunt; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] LDAP Authentication - Extended Errors
On 07/08/18 22:47, Mark Hunt wrote:
Hi,
I have been doing some development with Keycloak and specifically OpenID Connect,
Password Grant and an LDAP user federation with Active Directory. Overall everything is
working great but I am a little surprised that on a token refresh I get told that the user
account is disabled but on a login I do not. The exception to this would be if I try to
login with a disabled account after a user federation sync has occurred.
Is this a configuration issue or do you need to implement LDAP diagnostic messages for
login?
Not sure I understand. If you go to the admin console, are you seeing
the user is enabled or disabled here? Is user enabled or disabled in MSAD?
One thing to note is, that if you disabled the user directly in MSAD
after it was already synced to Keycloak, the user may be cached in the
Keycloak. So there may be some time needed until the latest information
about enabled/disabled state is propagated from MSAD to the Keycloak
side. You can try to clear the cache to check if it's the case. For long
term, you can tweak caching policy configuration of LDAP provider.
Marek
Thanks for developing a fantastic product!!
Regards
Mark
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user