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.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to