On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
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.
I found out that the password is working perfectly fine when ssh-ing
to an IPA machine. Also su works. But trying to logon to the WebUI
does not. I do get "The password or username you entered is
incorrect". Might be related to the fact that the user does not have
any kerberos specific LDAP attributes(apart from krbCanonicalName
and krbPrincipalName) after initial creation from the external
system.
As the password is set in plaintext from the external system there
should be a possibility for IPA to generate Kerberos keys etc. What
could I try?
It looks like IPA generates missing attributes after some time. When
I tried to login to the WebUI just seconds ago it worked. Can the
generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the
user from staging. Even after minutes. When I use this particular user
for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and
krbPrincipalKey are added almost immediately.
--
This is SSSD "migrating" the password. If migration mode is enabled and
SSSD can't get a Kerberos ticket it will do an LDAP bind instead which
will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration
page to set the keys.
Perfect. I can confirm that all required LDAP properties appear after I
do an LDAP bind manually.
What would probably be the best way to do this in an automated way? What
would you suggest?
--
_______________________________________________
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
