On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the
user has been activated, it works.
We are still facing this particular problem and do not have any
clue why the initial password set by the external system does not
work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS
expects hashed passwords in a specific format, e.g.
"{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and
100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords.
Kerberos does not work until the user's Kerberos key is generated
from a plain password, e.g. with a password change at
https://yourserver/ipa/migration/. SSSD can also detect the case and
generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read
and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially
created in the staging area the password does not seem to work. When
the user is activated and thus moved to the right place in the LDAP
tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed
immediately by 389DS. (PBKDF2_SHA256)
This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test
--last user testuser
This creates a staging user, sets their password to "MyPass1234", and
marks the password as expired. IPA always marks passwords as expired
when they are touched by a different user. They are ways to work
around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their
password.
By the way, you do not need migration mode if you are providing
cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run
into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which
scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To
disable password expiration, add the user DN of your service account to
the "passSyncManagersDNs" attribute of
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to
all your servers manually.
While writing the lines above another question came up in my mind:
Is there a way to forbid password modification for IPA users so that
users are forced to do that in an external sytem?
Yes, that's easy, remove the self service permission "Self can write own
password".
--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
