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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland