On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
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/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper
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.
If I try to set the userPassword attribute to some value with an LDAP
browser and chose "plaintext" the value gets hashed immediately. I do
see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true
Maximum username length: 32
Maximum hostname length: 64
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: ipatest.mydomain.at
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: True
Certificate Subject base: O=IPATEST.MYDOMAIN.AT
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at
IPA master capable of PKINIT: tipa01.ipatest.mydomain.at,
tipa02.ipatest.mydomain.at
IPA CA servers: tipa01.ipatest.mydomain.at
IPA CA renewal master: tipa01.ipatest.mydomain.at
Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may
provide more information, Minor (2529638972): KDC returned error string:
PROCESS_TGS
I should have done a little debugging instead of asking again. dirsrv
was not running after ipa config-mod --enable-migration=true
OK. Let me summarize... The whole procedure (creating a user in the
staging area if the password is a cleartext one) works if migration mode
is enabled. What drawbacks arise if migration mode is enabled all the time?
Cheers,
Ronald
--
_______________________________________________
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
