On Чцв, 09 сту 2025, Ronald Wimmer wrote:
On 09.01.25 12:49, Alexander Bokovoy wrote:
On Чцв, 09 сту 2025, Ronald Wimmer wrote:
On 09.01.25 02:23, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 1/8/25 20:59, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote: >On 2/13/24 18:54, Christian Heimes via FreeIPA-users wrote: >>On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote: >>>On 13.02.24 17:47, Rob Crittenden wrote: >>>>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? >>Because the IPA WebUI uses the Kerberos extension >>S4U2Proxy under the >>hood. It allows the WebUI to talk to the LDAP server on >>behalf of the >>user. This feature require a proper Kerberos credentials. See >>https://www.freeipa.org/page/V4/Service_Constraint_Delegation >> >>I already mentioned the recommended option to archive this a while >>ago. You may have missed the piece of information in this very long >>thread. IPA servers have a special /ipa/migration route (e.g. >>https://ipa.demo1.freeipa.org/ipa/migration/) for >>password migration. >>Under the hood the endpoint just does an LDAP bind with username and >>password. You can ask your users to either log into a >>machine with ssh >>or go to the migration page. >> >Did something change on the IPA side? We are using RedHat >IDM 4.12.2 and >these steps magically seem not to be required anymore. Kerberos >attributes are created immediately upon user creation. > What specifically seems to have changed?
rob
We have IPA in migration mode and create staged users with an external system. After that a job automatically activates users in the staging area.
IIRC all Kerberos properties were only created after a the user does an initial LDAP bind. (explicitly, via the web migration route, via SSH or some other method I am not aware of) But today I saw Kerberos attributes as the user was created in the staging area. (without an initial LDAP bind)
The question is: exactly what attributes are showing now that weren't in what older version?
It is possible that something changed. Knowing that will help find it.
Is this causing any problems for you?
We run IPA in migration mode and create users in IPA's staging area (pre-hashed clear-text password). These users are activated automatically. If no LDAP bind was done (either explicitly or implicitly) these users did not have any Kerberos properties. After an LDAP bind the password was hashed and Kerberos properties were created.
Until recently.
Now it seems that an LDAP bind is not required anymore. Kerberos properties exist from the beginning. (= user creation in staging area)
So. IPA's behaviour here changed obviously. Was this intentional or not? If it was intentional, why? If not, what happened?
There are no changes at all. There are two different ways of adding staged users and one of them is more efficient than the other in terms of provisioning Kerberos keys, so to say.
You can add staging user with
ipa stageuser-add foobar --first=Foo --last=Bar --password
and then you can see that this object already has Kerberos attributes with
ipa stageuser-show foobar --all --raw
It will show all objectclasses and krbPrincipalKey (if you specified a password) will also be generated.
Kerberos-related objectclasses are added when staging user is created.
If a clear password was set, then ipa-pwd-extop plugin will automatically generate krbPrincipalKey attribute values.
Another way to create a staging user is by performing an LDAP ADD to the staging area.
If you are using LDAP entry creation, then you control what LDAP attributes would be present in the entry. ipa-pwd-extop plugin cannot add krbPrincipalKey if no Kerberos objectclasses are present.
'ipa stageuser-activate' will add the required objectclasses, including Kerberos-related ones. It will not add a krbPrincipalKey because at the time when activation happens userPassword value in the stage entry is already hashed, so we don't have access to a clear-text password and users will need to explicitly bind to LDAP as this new user account to generate them. SSSD would do that bind on their behalf if you'd login to an enrolled system.
OK. Thanks for clarification, Alexander! I will double-check what happens because what I wrote is based on an "eyewhitness report" of a colleague.
So. Let me summarize this information for me personally. If we create a new user in the staging area via LDAP with a clear-text password it is impossible that the user can login using IPA's WebGUI as it requires Kerberos and the krbPrincipalKey is not available until an implicit or explicit LDAP bind is done with this exact user, right?
If you provided IPA-specific LDAP objectclasses (and their required attributes) when creating via LDAP, then you'll get Kerberos attributes created automatically and it will not require use of the migration mode.
Basically, it is fully controlled by your side -- if you are able to extend what is added to LDAP entry template, you can make it working.
Just look at how this entry looks after 'ipa stageuser-add' and model your LDAP update around it.