On Пан, 08 сту 2024, Ronald Wimmer wrote:
> On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
>> On 02.01.24 16:27, Rob Crittenden wrote:
>>> Ronald Wimmer via FreeIPA-users wrote:
>>>>
>>>>
>>>> On 14.12.23 14:42, Alexander Bokovoy wrote:
>>>>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
>>>>>> In our company we do have an IAM tool for user management. We
>>>>>> need to
>>>>>> create IPA users via this particular tool. I am aware of all IPA
>>>>>> commands or API calls to create/modify or delete a user.
>>>>>>
>>>>>> As the tool does not support FreeIPA yet they asked if there is a
>>>>>> way
>>>>>> to manage users by using LDAP only. Could that work? What about
>>>>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or
uidNumber?
>>>>>
>>>>> Learn about lifecycle management. This is your way of integrating
>>>>> with
>>>>> such tools bvy creating staged users:
>>>>>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
>>>>>
>>>>
>>>> I followed the instructions from the documentation.
>>>>
>>>> How could I possibly overcome
>>>>
>>>> Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
>>>> ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
>>>>
>>>> I need to set passwords from the external system.
>>>
>>> You need to enable migration mode (ipa config-mod --enable-migration
>>> true).
>>>
>>> By default a pre-hashed password can only be set once: during the user
>>> add operation.
>>
>> Ok. So this would not work for a password change. So if we need to
>> set an initial password and change that particular password in some
>> point in time the only feasible way is the IPA API, right?
>>
>> Can the immediate password expiration be overridden?
>
> As we have an upcoming please allow me to ask if I got the point here.
>
> I appreciate your support in this matter!
>
I was looking over the code. The only way to accept pre-hashed passwords
is when they also have Kerberos keys set. This means you cannot use
external LDAP modify/add for that as you cannot create the Kerberos key
without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is
either a cn=Directory Manager or a one from the passsync managers, it
would also not be marked for expiration immediately.
So. Am I right that our options are to use LDAP with a cleartext
passwort or use the IPA API?