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?