Ronald Wimmer via FreeIPA-users wrote:
> 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?
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged
user then immediately active them, that would be the time to do the
bind. Otherwise you have to store cleartext passwords and that is a
recipe for disaster.
User is created by an external tool. User activation in IPA is done by a
script on one of the IPA servers periodically. Sadly, the external tool
cannot do an initial LDAP bind in order to create a users's krb LDAP
attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen
if a user tries to login to IPA's WebGUI and the krb properties are
missing? Or is there another option for users to accomplish this?