Thanks Marek!
No big hurry for us to get it fixed so enjoy your holiday! :-)
I have created a JIRA issue as you suggested:
And I have tried some of the things you mentioned in order to get this working in the
Keycloak code but I have not managed to do so just yet. If I do I can probably create a
pull request indeed.
cheers
Edgar
On 14 Jan 2016, at 22:01, Marek Posolda <mposolda(a)redhat.com>
wrote:
This makes things a bit tricky. Because:
1) Our current model SPI and federation SPI for update credential doesn't differ
between the case when user is updating his credential or when admin is resetting the
credential of user.
2) Also in LDAP both operations are executed under "admin" connection (user own
connection is used just to verify his password).
3) Finally there is no old password available in the UserModel.updateCredential
operation
Feel free to create JIRA, but hard to promise when we will be able to look into it (I am
on holiday next week and then we have feature freeze and won't be able to add new
stuff like this).
So if you really want it, you may need to send PR by yourself. The implementation may
require more changes. Some pointers how I would do it (we may need ACK from other team
members to confirm as we are close to "feature freeze" phase right now until we
start on keycloak 2.x development):
1) Change UserCredentialModel and put new fields "oldValue" with the old
password. Also maybe the boolean field "isAdminCall", which will be true if
admin is restarting the password (in this case the LDAP operation can be same like already
and use "replace" operation) or if user himself is restarting the password.
Maybe the "isAdminCall" field is not necessary as with admin call, the
"oldValue" simply won't be available (when user himself is restarting the
password in account management, user is required to set password and AccountService knows
the old password value)
Other possibility is to introduce the context map ( Map<String, String> contextData
) on UserCredentialModel, which is more flexible. At the same time the "device"
field can be removed from UserCredentialModel IMO as it doesn't seem to be used from
anywhere right now.
2) Change the LDAPIdentityStore implementation to differ between the two cases you
described
Marek
On 14/01/16 17:41, Edgar Vonk - Info.nl wrote:
> Regarding the MSAD password history policy not being used when we change the user’s
password through Keycloak (using Keycloak’s user account screen where the user is updating
his/her own password): is this maybe not caused because in the code the change password
request to MSAD is not done ‘correctly’? If I look at LDAPIdentityStore#updateADPassword
it seems that changing the password involves a replace operation and not a delete + add
operation? If I understand the documentation from Microsoft correctly I think you need to
do a delete + add operation when the user changes his/her own password and the replace
operation only when an admin changes someone else’s password. I think this might explain
why the password history policy is not adhered to?
>
> From
https://support.microsoft.com/en-us/kb/269190:
<
https://support.microsoft.com/en-us/kb/269190:>
> "There are two possible ways to modify the unicodePwd attribute. The first is
similar to a normal "user change password" operation. In this case, the modify
request must contain both a delete and an add operation. The delete operation must contain
the current password with quotes around it. The add operation must contain the desired new
password with quotes around it.
>
> The second way to modify this attribute is analogous to an administrator resetting a
password for a user. In order to do this, the client must bind as a user with sufficient
permissions to modify another user's password. This modify request should contain a
single replace operation with the new desired password surrounded by quotes. If the client
has sufficient permissions, this password become the new password, regardless of what the
old password was."
>
>
>
>> On 14 Jan 2016, at 12:09, Edgar Vonk - Info.nl <
http://info.nl/>
<Edgar(a)info.nl <mailto:Edgar@info.nl>> wrote:
>>
>> Ah, sorry about this. I had not added a MSAD User Account Control mapper in our
existing AD user federation in Keycloak yet. I thought it might be implicit and that I
would not have to define an actual mapper or something. However this fixed the synching of
the enabled status between AD and Keycloak. Nice work!
>>
>>
>>
>>
>>> On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl <
http://info.nl/>
<Edgar(a)info.nl <mailto:Edgar@info.nl>> wrote:
>>>
>>> Hi Marek,
>>>
>>>> On 14 Jan 2016, at 10:28, Marek Posolda <
<mailto:mposolda@redhat.com>mposolda@redhat.com
<mailto:mposolda@redhat.com>> wrote:
>>>>
>>>> Yeah, the new MSAD mapper added in 1.8 should help you with this. Once
the user has in MSAD userAccountControl of 514, he will be marked as disabled in Keycloak.
Then when you enable it in Keycloak, it should be propagated to MSAD and user will be put
in MSAD to 512. Hope it will work for you.
>>>>
>>>
>>>
>>> Thanks but I’m afraid it does not work for us. I am using Keycloak 1.8.0.CR1
now. When I disable the user in MSAD I see the userAccountControl attribute change to 514,
however this is not reflected in Keycloak. Not even when I force a resync of all users.
>>>
>>> I will see if I can do some debugging and create a JIRA issue for you.
>>>
>>> cheers
>>>
>>> Edgar
>>>
>>>
>>>> Not sure about password history issue.
>>>>
>>>> Will wait for your feedback. Hope we can sort your issues.
>>>>
>>>> Marek
>>>>
>>>> On 14/01/16 10:01, Edgar Vonk - Info.nl <
http://info.nl/> wrote:
>>>>> Hi Marek,
>>>>>
>>>>> Sorry, I overlooked you mentioning that you added this in Keycloak
1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!
>>>>>
>>>>> Thanks again for your help.
>>>>>
>>>>> cheers
>>>>>
>>>>> Edgar
>>>>>
>>>>>
>>>>>> On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl
<
http://info.nl/> < <mailto:Edgar@info.nl>Edgar@info.nl
<mailto:Edgar@info.nl>> wrote:
>>>>>>
>>>>>> Hi Marek,
>>>>>>
>>>>>> Thanks very much for your reply. See remarks below.
>>>>>>
>>>>>>> On 13 Jan 2016, at 22:53, Marek Posolda <
<mailto:mposolda@redhat.com>mposolda@redhat.com
<mailto:mposolda@redhat.com>> wrote:
>>>>>>>
>>>>>>> On 13/01/16 13:40, Edgar Vonk - Info.nl
<
http://info.nl/> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We use Keycloak’s user federation to integrate with a
(Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD
and also want to manage the password policies from AD so we do not have any password
policies in Keycloak set up. We also want to use Keycloak for all user management
functionality. We have set up the password policies in AD at the domain level where we
connect to from Keycloak.
>>>>>>>>
>>>>>>>> Our password policies in AD are as follows:
>>>>>>>> - password complexity (min length + special chars)
>>>>>>>> - account lock out after 3 attempts
>>>>>>>> - password history (not allowed to use previous 5
passwords)
>>>>>>>>
>>>>>>>> Users and admins can set and change passwords in AD from
Keycloak fine. However the password policies do not quite do what we want them to:
>>>>>>>> - Password complexity policy seems to work fine.
>>>>>>>> - Account is indeed locked in AD after three failed
attempts. However the ‘Unlock users’ functionality in Keycloak does not unlock the users
in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do
this from Keycloak however (and really per user and not for all users in one go). Should
this work in Keycloak or is this a new feature request?
>>>>>>> Is the fact that user is locked tracked in your MSAD through
userAccountControl attribute?
>>>>>>
>>>>>> Yes it is. I see this working when I look at a normal LDAP
browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl
attribute change from 512 to 514.
>>>>>>
>>>>>>
>>>>>>> In the Keycloak 1.8 I've added the MSAD
UserAccountControl mapper, which allows to integrate the MSAD account state more tightly
into Keycloak state. For example enable user in Keycloak admin console will remove the
ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this
user in MSAD too.
>>>>>>
>>>>>>
>>>>>> This sounds good, however unfortunately we do not see this
happening. When I disable the user in Keycloak the userAccountControl attribute does not
change at all so the propagation to MSAD does not seem to work here.
>>>>>>
>>>>>> We have indeed configured the user federation in Keycloak to
WRITABLE LDAP and all other user attributes (like user name etc) are propagated from
Keycloak to MSAD just fine.
>>>>>>
>>>>>> I will create a JIRA issue so that I can send you some more
details.
>>>>>>
>>>>>>>
>>>>>>> However support for lock/unlock is not included in the mapper
though. So feel free to create JIRA.
>>>>>>>
>>>>>>
>>>>>> Ok, will do.
>>>>>>
>>>>>>
>>>>>>> Until it's implemented, you can possibly use adminEvent
listener (There is admin event triggered when you click "Unlock user" in
Keycloak UI. So you can listen to this event and propagate the call to MSAD once you
successfully enable it)
>>>>>>>> - The password history policy does not seem to work at
all. Users can currently set their password to a previous password without a problem. Does
anyone have an idea why this policy in AD does not work from Keycloak?
>>>>>>> No idea. Keycloak is just using Directory API for change
password. It's strange the MSAD allows to change password through this API when it
breaks password history policy. Are you sure you have WRITABLE LDAP and password update
from Keycloak is propagated to MSAD?
>>>>>>
>>>>>> Yes, we have writable ldap configured and indeed the password is
propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl
attribute.
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>> Edgar
>>>>>>
>>>>>>>
>>>>>>> Marek
>>>>>>>>
>>>>>>>> cheers
>>>>>>>>
>>>>>>>> Edgar
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>>
<mailto:keycloak-dev@lists.jboss.org>keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>>>>
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>https://lists.jb...
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>
>>>>
>>>
>>
>