3:30 a.m.
Hi,
In the microsoft management tools there is a checkbox: "user must change
password at next logon". If I check that box, keycloak 2.5 gives us a
logon failure.
Perhaps it would be only a rather small change, to map that MSAD
checkbox ("Pwd-Last-Set" = 0) to the equivalent in keycloak:
"credentials" / "temporary" switch. So the next time a user is asked
to
change his/her password.
More MS info here:
https://msdn.microsoft.com/en-us/library/ms679430
And, and thanks very much very much for the recent fix of issue 2333, on
MSAD password policies! Much appreciated! :-)
MJ
4:47 a.m.
Hmm... I think this should be already working?
I've just tested the usecase:
- Keycloak with configured writable MSAD and with "MSAD Account
controls" mapper available
- User "john" from LDAP authenticated in Keycloak successfully
- Then I changed in the LDAP the "john" user record the value of
"pwdLastSet" attribute to 0
- Then login again as "john" in Keycloak. I am asked to change my
password. After this change is user authenticated successfully and also
his LDAP record has "pwdLastSet" updated back to the current time.
I am testing with latest master though.
Can you doublecheck this scenario on your side? Are you using latest
Keycloak master?
Marek
On 24/01/17 10:30, mj wrote:
Hi,
In the microsoft management tools there is a checkbox: "user must change
password at next logon". If I check that box, keycloak 2.5 gives us a
logon failure.
Perhaps it would be only a rather small change, to map that MSAD
checkbox ("Pwd-Last-Set" = 0) to the equivalent in keycloak:
"credentials" / "temporary" switch. So the next time a user is asked
to
change his/her password.
More MS info here:
https://msdn.microsoft.com/en-us/library/ms679430
And, and thanks very much very much for the recent fix of issue 2333, on
MSAD password policies! Much appreciated! :-)
MJ
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:08 a.m.
Hi Marek,
On 01/24/2017 11:47 AM, Marek Posolda wrote:
Can you doublecheck this scenario on your side? Are you using latest
Keycloak master?
So I double checked. We are using 2.5.0, NOT latest master, but it does
NOT work:
As soon as I check "user must change password on next logon", the MSAD
attribute pwdLastSet changes to 0. (that is correct, confirmed with an ldif)
However, keycloak tells me: invalid username or password. Removing the
checkbox sets pwdLastSet to -1, and the logon succeeds again.
Searching through jira, I don't see an explanation for the difference in
behaviour between 2.5.0 and 2.5.1. If I can find some time, I'll try
installing 2.5.1, to see if it works there...
MJ
4:47 a.m.
On 26/01/17 11:08, mj wrote:
Hi Marek,
On 01/24/2017 11:47 AM, Marek Posolda wrote:
> Can you doublecheck this scenario on your side? Are you using latest
> Keycloak master?
So I double checked. We are using 2.5.0, NOT latest master, but it
does NOT work:
As soon as I check "user must change password on next logon", the MSAD
attribute pwdLastSet changes to 0. (that is correct, confirmed with an
ldif)
However, keycloak tells me: invalid username or password. Removing the
checkbox sets pwdLastSet to -1, and the logon succeeds again.
Searching through jira, I don't see an explanation for the difference
in behaviour between 2.5.0 and 2.5.1. If I can find some time, I'll
try installing 2.5.1, to see if it works there...
There were some changes for the
KEYCLOAK-2333 and KEYCLOAK-4069, which
were related to this. If upgrade to 2.5.1 won't help for you, then could
you enable DEBUG logging for the "org.keycloak.storage.ldap" in
standalone.xml and attach your log?
Thanks,
Marek
MJ
3:09 a.m.
Hi Marek,
On 01/26/2017 11:47 AM, Marek Posolda wrote:
There were some changes for the KEYCLOAK-2333 and KEYCLOAK-4069,
which were related to this. If upgrade to 2.5.1 won't help for you,
then could you enable DEBUG logging for the
"org.keycloak.storage.ldap" in standalone.xml and attach your log?
Tested with 2.5.1,a and the behaviour remains. Debug log tells me:
2017-01-27 09:49:22,664 DEBUG
[org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager]
(default task-10) Authentication failed for DN
[CN=username,CN=Users,DC=samba,DC=company,DC=com]:
javax.naming.AuthenticationException: [LDAP: error code 49 - Simple
Bind Failed: NT_STATUS_PASSWORD_MUST_CHANGE]
Could you tell me the domain functional level of your AD environment?
I have the feeling that the behaviour might be different between
different functional levels.
MJ
3:58 a.m.
Hi Marek,
So, I found out a bit more. It seems that there is a difference between
samba, and a real AD.
The Errorcode is the same (49), but the additional information is NOT
exactly the same. Please compare:
Samba4:
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: Simple Bind Failed: NT_STATUS_PASSWORD_MUST_CHANGE
MSAD
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 773, v1db1
There is a samba bugreport about this here:
https://bugzilla.samba.org/show_bug.cgi?id=9048
However, if keycloak would rely only on the Errorcode 49, password would
work with _both_ samba and MSAD.
Would it be possible to change keycloak like that?
MJ
4:21 a.m.
On 01/27/2017 10:58 AM, mj wrote:
However, if keycloak would rely only on the Errorcode 49, password
would
work with _both_ samba and MSAD.
Would it be possible to change keycloak like that?
Ah no. It seems that 49 is actually a whole range of logon failures,
including
- expired
- disabled
- user not found
Hmm. :-(
5:52 a.m.
On 27/01/17 11:21, mj wrote:
On 01/27/2017 10:58 AM, mj wrote:
> However, if keycloak would rely only on the Errorcode 49, password would
> work with _both_ samba and MSAD.
>
> Would it be possible to change keycloak like that?
Ah no. It seems that 49 is actually a whole range of logon failures,
including
- expired
- disabled
- user not found
Hmm. :-(
Yes, exactly. That's not sufficient...
Actually we don't test and officially support Samba AD, just the MSAD.
We may add that in the future though as there are more people asking for
that, but each LDAP vendor adds some overhead for testing etc...
So for now, you would need to add your own implementation of LDAP
mapper. I guess it can be subclass of
MSADUserAccountControlStorageMapper with some overriden methods (like
onAuthenticationFailure with the specific logic for parsing Samba AD
error, which is different than MSAD + maybe some more).
You can send PR to contribute the mapper for Samba AD if you manage to
have it working. Ideally also with the writable scenarios like
passwordUpdate, disable user in KC will disable him in AD etc.
Marek
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:15 p.m.
Hi Marek, list,
Actually we don't test and officially support Samba AD, just the
MSAD.
Yeah I know. And (usually, so far) everything that works with MSAD works
also with samba4, this is actually the first time we are running into a
compatibility issue like this.
You can send PR to contribute the mapper for Samba AD if you manage
to
have it working. Ideally also with the writable scenarios like
passwordUpdate, disable user in KC will disable him in AD etc.
All those things
should normally work exactly as they do with MSAD.
Andrew Bartlett (core samba dev) pointed me to the following file:
https://github.com/keycloak/keycloak/blob/b2d1a1a17fc8f665f4ba83d62e3c22d...
written by you.
I was thinking (being no programmer at all!!!) that I could simple edit
a line slightly, to watch for "NT_STATUS_PWD_MUST_CHANGE" instead of the
MSAD output.
That would give me a MSADUserAccountControlStorageMapper 'version'
targetted for samba4, as for the rest no changes should be required at all.
However...in my keycloak install, I cannot find the file
MSADUserAccountControlStorageMapper.java, so I guess that bright idea is
also not an option.
It seems such a waist of energy to create a complete subclass of
MSADUserAccountControlStorageMapper, given that the only difference is
to look for "NT_STATUS_PWD_MUST_CHANGE"....
Any place I could edit, to change that in an installed keycloak?
MJ
2:07 a.m.
On 27/01/17 21:15, mj wrote:
Hi Marek, list,
> Actually we don't test and officially support Samba AD, just the MSAD.
Yeah I know. And (usually, so far) everything that works with MSAD
works also with samba4, this is actually the first time we are running
into a compatibility issue like this.
> You can send PR to contribute the mapper for Samba AD if you manage to
> have it working. Ideally also with the writable scenarios like
> passwordUpdate, disable user in KC will disable him in AD etc.
All those things should normally work exactly as they do with MSAD.
Andrew Bartlett (core samba dev) pointed me to the following file:
https://github.com/keycloak/keycloak/blob/b2d1a1a17fc8f665f4ba83d62e3c22d...
written by you.
I was thinking (being no programmer at all!!!) that I could simple
edit a line slightly, to watch for "NT_STATUS_PWD_MUST_CHANGE" instead
of the MSAD output.
That would give me a MSADUserAccountControlStorageMapper 'version'
targetted for samba4, as for the rest no changes should be required at
all.
However...in my keycloak install, I cannot find the file
MSADUserAccountControlStorageMapper.java, so I guess that bright idea
is also not an option.
The java files are not inside the server distribution. Java
works in a
way, that Java files (sources) are compiled to the class files and then
packed in JAR archives. There is no easy way to change the source of the
existing class inside the archive and rewrite something directly.
It seems such a waist of energy to create a complete subclass of
MSADUserAccountControlStorageMapper, given that the only difference is
to look for "NT_STATUS_PWD_MUST_CHANGE"....
Any place I could edit, to change that in an installed keycloak?
Well, if logic is
really the same, the Samba4 specific subclass doesn't
need to have everything forked (copy/pasted). It can just override one
single method (onAuthenticationFailure). That's one of the benefits of
inheritance. So the way to go is really to create separate mapper for
Samba4 and deploy it as a Keycloak provider.
You can take a look at Server Developer Guide [1] and "provider"
examples in our example distribution. Unfortunately it requires to have
some programmer and Java knowledge, so not sure if helpful for you.
However I don't have anything better ATM, sorry... Our position is to
not add more supported LDAP servers, like Samba4, by ourselves. So
Samba4 would need to be community contribution (from you or someone
else). Also we will need to rely on community for additional maintenance
and testing.
[1] https://keycloak.gitbooks.io/server-developer-guide/content/
Marek
MJ
5:56 a.m.
Hi Marek,
On 30-1-2017 9:07, Marek Posolda wrote:
programmer and Java knowledge, so not sure if helpful for you.
However I
don't have anything better ATM, sorry... Our position is to not add more
supported LDAP servers, like Samba4, by ourselves. So Samba4 would need
to be community contribution (from you or someone else). Also we will
need to rely on community for additional maintenance and testing.
I completely understand your position. Even Andrew Bartlett stated
similar on the samba mailinglist:
I think this is a Samba fix. If they want to support old Samba,
watching for NT_STATUS_PWD_MUST_CHANGE would also work.
Best regards,
MJ
8:03 a.m.
Hi Marek, list,
On 01/27/2017 12:52 PM, Marek Posolda wrote:
Actually we don't test and officially support Samba AD, just the
MSAD.
We may add that in the future though as there are more people asking for
that, but each LDAP vendor adds some overhead for testing etc...
An update on the above:
We are now collection quotations on making samba's output compatible
with MSAD in the case of "NT_STATUS_PWD_MUST_CHANGE”. So with a bit of
luck, future samba will behave just like MSAD in that case.
There is another question that we have: Is keycloak supposed to import
the pwdLastSet field for a user, in the case of an MSAD backend?
If keycloak imports that field, it would be able enforce keycloaks own
password max age policy also on MSAD federated accounts.
Password age adherance is such a vital bit of functionality, to make
keycloak a viable competitor of microsofts own AD federation services.
MJ
2640
days inactive
2649
days old
11 comments
3 participants
participants (3)
-
lists -
Marek Posolda -
mj