[Freeipa-users] Re: Create IPA user via LDAP
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}10$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.
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
[Freeipa-users] Re: SSSD offline and AD authentication issues
On Пан, 12 лют 2024, Heidi Hough via FreeIPA-users wrote: I appreciate the feedback. I added the ldap_search_timeout to both the server and client sssd.conf files. I experimented with different values with no additional success. Please find sanitized client and server sssd logs from my login attempt with ldap_search_timeout = 30. Client https://privatebin.net/?8b3b376c2cf445ac#DwWqNUD96mcHqBYoNi7u97n9ZZ6ZNYeVDTrut6W91aK6 Server https://privatebin.net/?f8a35b7c92fae546#DT3sHCD9kY7h3UZrRSBX8VbBkmccRCVkgguaX3NG6bDG Hi, it looks like you have restarted the server during the time when a client request was issued. As a result, not only the server logs contain no request information, it was not really served and thus failed: from client side: (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=ad-he...@ad.contoso.com] (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [dp_attach_req] (0x0400): [RID#2] DP Request [Account #2]: REQ_TRACE: New request. Flags [0x0001]. (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [dp_attach_req] (0x0400): [RID#2] Number of active DP request: 1 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ad.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ad.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_print_server] (0x2000): [RID#2] Searching 172.16.50.102:389 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_get_generic_ext_step] (0x0400): [RID#2] calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=ad-heidi))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc =subdomain,dc=contoso,dc=com]. (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_get_generic_ext_step] (0x2000): [RID#2] ldap_search_ext called, msgid = 14 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#2] New operation 14 timeout 30 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], ldap[0x55c25d1006b0] (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_get_generic_op_finished] (0x0400): [RID#2] Search result: Success(0), no errmsg set (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_destructor] (0x2000): [RID#2] Operation 14 finished (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] (0x1000): [RID#2] Domain ad.contoso.com is Active (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_acct_info_send] (0x0400): [RID#2] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [ad-heidi] to IPA server (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x0400): [RID#2] Executing extended operation (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x2000): [RID#2] ldap_extended_operation sent, msgid = 15 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#2] New operation 15 timeout 30 (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], ldap[0x55c25d1006b0] (2024-02-12 8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2024-02-12 8:49:03): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], ldap[0x55c25d1006b0] (2024-02-12 8:49:03): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_done] (0x0040): [RID#2] ldap_extended_operation result: Time limit exceeded(3), (null). The request is sent at 8:48:40. Assuming the time is the same, the server side did not start at that point yet: (2024-02-12 8:48:24): [be[ipa.subdomain.consoto.com]] [be_ptask_execute] (0x0400): Task [Cleanup [id] of ad.contoso.com]: executing task, timeout 30 seconds (2024-02-12 8:48:24): [be[ipa.subdomain.consoto.com]] [sysdb_cache_search_users] (0x2000): Search users with filter: (&(objectCategory=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1707756504)(!(lastLogin=* (2024-02-12 8:48:44): [be[ipa.subdomain.consoto.com]] [server_setup] (0x3f7c0): Starting with debug level = 0x3ff0 (2024-02-12 8:48:44): [be[ipa.subdomain.consoto.com]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
[Freeipa-users] Re: SSSD offline and AD authentication issues
I appreciate the feedback. I added the ldap_search_timeout to both the server and client sssd.conf files. I experimented with different values with no additional success. Please find sanitized client and server sssd logs from my login attempt with ldap_search_timeout = 30. Client https://privatebin.net/?8b3b376c2cf445ac#DwWqNUD96mcHqBYoNi7u97n9ZZ6ZNYeVDTrut6W91aK6 Server https://privatebin.net/?f8a35b7c92fae546#DT3sHCD9kY7h3UZrRSBX8VbBkmccRCVkgguaX3NG6bDG Thanks Heidi -- ___ 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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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.
--
___
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
[Freeipa-users] Re: reliability of external radius
ugh. It doesn't look like we can do this until this patch happens. The actual authentication would use DUO. Since that requires the user to respond, the delay could be significant. 10 sec is definitely not enough. This looks like a client patch. We're using Ubuntu for our clients. (RHEL for the KDCs.) We have purchased support, but the PO is waiting in Purchasing. So I may be able to help get it into Ubuntu. From: Alexander Bokovoy Sent: Monday, February 12, 2024 2:45 PM To: FreeIPA users list Cc: Charles Hedrick Subject: Re: [Freeipa-users] reliability of external radius On Пан, 12 лют 2024, Charles Hedrick via FreeIPA-users wrote: >Currently our department uses passwords in IPA, with a few users using >OTP. I'm considering using a University radius server for most users. >Are there reliability implications? My concern is what happens if the >radius server is slow to respond or even is down. I'd like users with >accounts in IPA to still work, and I'd hope things would survive >conditions of slow response. There is one potential issue that we fixed recently in MIT Kerberos: https://github.com/krb5/krb5/pull/1318 It is not yet part of any release. If you have RHEL subscription, making it known to RHEL support organization might help to get this fix out faster. -- / 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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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.
--
/ 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
[Freeipa-users] Re: reliability of external radius
On Пан, 12 лют 2024, Charles Hedrick via FreeIPA-users wrote: Currently our department uses passwords in IPA, with a few users using OTP. I'm considering using a University radius server for most users. Are there reliability implications? My concern is what happens if the radius server is slow to respond or even is down. I'd like users with accounts in IPA to still work, and I'd hope things would survive conditions of slow response. There is one potential issue that we fixed recently in MIT Kerberos: https://github.com/krb5/krb5/pull/1318 It is not yet part of any release. If you have RHEL subscription, making it known to RHEL support organization might help to get this fix out faster. -- / 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
[Freeipa-users] Re: Installing CA certificate isuue
mskaraca--- via FreeIPA-users wrote: > Hi > > I just wanted to say thank you to this list and especially to Rob > Crittenden.. > > I could not log in to freeipa-users, there may be a problem in logging > in with social network accounts. So I am sending this as an email.. > > Firstly My issue was freeIpa was refusing to install my comodo > certificate with a signature algorithm complain. > > I am writing how I solved this issue with a complete CLI > > #recommended by Rob and significant milestone in solving my problem > update-crypto-policies --set DEFAULT:SHA1 > #I received ca-bundle from my CA with my CRT file > sudo ipa-cacert-manage -t C,, install my-domain.ca-bundle > sudo ipa-certupdate > #pem file incudes all the certificate authority chain.. > sudo ipa-server-certinstall --http --dirsrv mydomain.key mydomain.pem > > > > I have only one question > Why didIı need to add this ca file to my freeIPA server? I mean it is > already sgined with a public CA? web servers can easily see and do not > throw any error when I install this certificate. but same is not true > when I install this certificate in IDM or in anyting other than a web > server.. so why do they not know my CA automaticaly? > > is it because this is especially designed for HTTPS connections? Do I > need to request something different or from another vendor, such as verisgn? Not every public CA chain is present on all machines. The chain is installed on the server using ipa-cacert-manage so it can be distributed to clients with ipa-certupdate. Your certificate is probably fine, though SHA-1 is deprecated. For more details see https://en.wikipedia.org/wiki/SHA-1 rob -- ___ 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
[Freeipa-users] Re: idrange problem
On Пят, 02 лют 2024, Tomasz Torcz via FreeIPA-users wrote: On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via FreeIPA-users wrote: On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote: > Is there anyway to just delete all these SID requirements? My ipa > domain doesn't have a trust to anything windows and there's no plan to > ever set that up. No. S4U protocol extensions for Kerberos are requiring PAC buffers presence as per the MS-SFU spec. The changes came in in 2021 as a part of the fixes to 'dollar sign attack'. You can get a partial view of that with https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or several talks we gave over past few years at various conferences. Most notable: - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket Attack" https://www.youtube.com/watch?v=1BnraIAcybg - Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT Kerberos: path out of experimental" https://www.youtube.com/watch?v=0_cdYuIYw0o Those attacks are against MS Windows (and Samba?) I would say they're not relevant to majority of FreeIPA deployments, which have nothing to do with Windows. You are wrong here. It is a common problem since majority of users do not understand Kerberos protocol extensions and their use by FreeIPA or other domain services like Samba AD or Active Directory. Since its inception, FreeIPA has depended on S4U extensions to Kerberos to allow IPA services operate on behalf of users. This is used by IPA API, for example, to allow IPA management framework to talk to LDAP on behalf of the user and LDAP server to recognize that this connection is authenticated as the user, not IPA management framework account. This extension was developed by Microsoft for Active Directory to allow domain member machines to operate on behalf of the user when mounting home directories (shares) or allowing web servers to ask for other resources (file shares or SQL server connections) on behalf of the user. All these technical elements are part of a constrained delegation feature that both Active Directory implementations and FreeIPA are using internally. You can read about constrained delegation forms in more details in [1]. There are several different attacks that were developed against S4U extensions and they are protocol level attacks. A Kerberos ticket received by the service through S4U2Self extension is supposed to be non-forwardable but 'forwardable' bit is placed in the area which is under control of the service asking for the ticket. Hence, a rogue service can flip the 'forwardable' bit and KDC will not be able to tell the difference: the area is checksummed with a key based on the service's key. It was supposed to be a protocol extension that only allowed issuing tickets to itself and not allowing to use it elsewhere. It is not anymore: this bit flip allows to use a ticket printed by the rogue service against any other allowed service in the environment using the second part of S4U extensions, S4U2Proxy. The latter is the extension used by IPA as the core one for IPA API operations. To prevent this attack, a protocol change was added to introduce additional checksums which aren't under control of the rogue service. There are actually two separate checksums: one them was found to be possible to attack via pre-imaging operation against the hash algorithm, so another one was added to close the problem down. The only way to prevent these attacks on the checksums and Kerberos ticket properties was by introducing additional details in the tickets that cannot be controlled by the attackers. This is done via a set of extensions that handle authorization data (AD) information in the Kerberos tickets. MS-PAC describes one of AD buffer types and PAC records are required for S4U operations. Use of S4U operations since 2020 requires several types of PAC records, all protected from modifications. On top of that, use of Kerberos tickets without PAC information opens an easy attack vector to POSIX environments. PAC allows KDC to place identity details into Kerberos tickets so that Kerberos services can corelate Kerberos principal with the information they know about identity of this principal in their environment. Since SSSD and Samba (winbindd) do explicit SID to POSIX user/group name translation, information from PAC records can be used to identify not just the Kerberos principal to POSIX account/group mapping but also to figure out whether this principal is of right shape (e.g. it is a valid user rather than a service or a machine account). This prevents mistyping attacks like mapping a machine account 'root$' to 'root' POSIX user. People in both white hat and black hat communities weren't really attacking FreeIPA through these issues because most of the tools they use lack features required by the Kerberos implementation in FreeIPA. For example, FreeIPA defaults to newer Kerberos encryption types defined in RFC 8009
[Freeipa-users] Re: idrange problem
On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via FreeIPA-users wrote: > On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote: > > Is there anyway to just delete all these SID requirements? My ipa > > domain doesn't have a trust to anything windows and there's no plan to > > ever set that up. > > No. > > S4U protocol extensions for Kerberos are requiring PAC buffers presence > as per the MS-SFU spec. The changes came in in 2021 as a part of the > fixes to 'dollar sign attack'. You can get a partial view of that with > https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or > several talks we gave over past few years at various conferences. Most > notable: > - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket > Attack" > https://www.youtube.com/watch?v=1BnraIAcybg > > - Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT > Kerberos: path out of experimental" > https://www.youtube.com/watch?v=0_cdYuIYw0o Those attacks are against MS Windows (and Samba?) I would say they're not relevant to majority of FreeIPA deployments, which have nothing to do with Windows. -- Tomasz Torcz“Funeral in the morning, IDE hacking to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox -- ___ 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
[Freeipa-users] reliability of external radius
Currently our department uses passwords in IPA, with a few users using OTP. I'm considering using a University radius server for most users. Are there reliability implications? My concern is what happens if the radius server is slow to respond or even is down. I'd like users with accounts in IPA to still work, and I'd hope things would survive conditions of slow response. -- ___ 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
[Freeipa-users] Re: Create IPA user via LDAP
On 12.02.24 14:36, Christian Heimes via FreeIPA-users wrote: On 12/02/2024 14.15, Christian Heimes wrote: While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem? Yes, that's easy, remove the self service permission "Self can write own password". Actually, it's not *that* trivial. Alexander just pointed out to me, that this will break service and host accounts requesting their own keytab. Ops! You may be able to archive the desired effect by replacing the ACI with a different self-service ACI that permits self-write for everybody except externally managed user accounts. Perhaps you can add your external users to a non-POSIX group and add a filter like (targetfilter = "(memberOf!=cn=external-passwords,cn=groups,cn=accounts,$SUFFIX)") to the self-service ACI. That's a great idea. Thanks for that! -- ___ 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
[Freeipa-users] Re: Requiring OTP thru PAM+LDAP
On Пан, 12 лют 2024, G H via FreeIPA-users wrote:
I am using SSSD in LDAP-only mode (no kerberos at all), communicating
with FreeIPA. For certain hosts, I want to require sssd to demand OTP.
Right now, they are allowing password OR password+OTP. But my 'ipa
show-host' output for the hosts in question have "Authentication
Indicators: otp". What do I need to do for sssd to only accept
password+OTP ?
Authentication indicators are Kerberos-only.
The way to enforce OTP use by the LDAP client during bind is by adding a
control OTP_REQUIRED_OID (2.16.840.1.113730.3.8.10.7) during LDAP SASL
bind like how ipa-otpd daemon does:
LDAPControl control = { OTP_REQUIRED_OID, {}, true };
LDAPControl *ctrls[] = { , NULL };
...
cred.bv_val = data->data;
cred.bv_len = data->length;
i = ldap_sasl_bind(verto_get_private(ev), item->user.dn, LDAP_SASL_SIMPLE,
, ctrls, NULL, >msgid);
I don't think it is possible to do so by SSSD as it is.
I have a proposal https://github.com/freeipa/freeipa/pull/7200 that
enforces OTP over *all* LDAP binds server-side, by effectively assuming
this OID is present always in any client LDAP bind.
--
/ 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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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?
--
___
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
[Freeipa-users] Requiring OTP thru PAM+LDAP
I am using SSSD in LDAP-only mode (no kerberos at all), communicating with FreeIPA. For certain hosts, I want to require sssd to demand OTP. Right now, they are allowing password OR password+OTP. But my 'ipa show-host' output for the hosts in question have "Authentication Indicators: otp". What do I need to do for sssd to only accept password+OTP ? Thank you. -- ___ 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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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?
--
___
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
[Freeipa-users] Re: Create IPA user via LDAP
On 12/02/2024 14.15, Christian Heimes wrote: While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem? Yes, that's easy, remove the self service permission "Self can write own password". Actually, it's not *that* trivial. Alexander just pointed out to me, that this will break service and host accounts requesting their own keytab. Ops! You may be able to archive the desired effect by replacing the ACI with a different self-service ACI that permits self-write for everybody except externally managed user accounts. Perhaps you can add your external users to a non-POSIX group and add a filter like (targetfilter = "(memberOf!=cn=external-passwords,cn=groups,cn=accounts,$SUFFIX)") to the self-service ACI. Christian -- Christian Heimes Principal Software Engineer, Identity Management and Platform Security Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -- ___ 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
[Freeipa-users] Re: Installing CA certificate isuue
Hi I just wanted to say thank you to this list and especially to Rob Crittenden.. I could not log in to freeipa-users, there may be a problem in logging in with social network accounts. So I am sending this as an email.. Firstly My issue was freeIpa was refusing to install my comodo certificate with a signature algorithm complain. I am writing how I solved this issue with a complete CLI #recommended by Rob and significant milestone in solving my problemupdate-crypto-policies --set DEFAULT:SHA1#I received ca-bundle from my CA with my CRT file sudo ipa-cacert-manage -t C,, install my-domain.ca-bundle sudo ipa-certupdate #pem file incudes all the certificate authority chain.. sudo ipa-server-certinstall --http --dirsrv mydomain.key mydomain.pem I have only one questionWhy didIı need to add this ca file to my freeIPA server? I mean it is already sgined with a public CA? web servers can easily see and do not throw any error when I install this certificate. but same is not true when I install this certificate in IDM or in anyting other than a web server.. so why do they not know my CA automaticaly? is it because this is especially designed for HTTPS connections? Do I need to request something different or from another vendor, such as verisgn? Thanks again.. -- ___ 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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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.
While writing the lines above another question came up in my mind:
Is there a way to forbid password modification for IPA users so that
users are forced to do that in an external sytem?
Yes, that's easy, remove the self service permission "Self can write own
password".
--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
--
___
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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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?
While writing the lines above another question came up in my mind:
Is there a way to forbid password modification for IPA users so that
users are forced to do that in an external sytem?
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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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.
--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
--
___
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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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)
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
[Freeipa-users] Re: Create IPA user via LDAP
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}10$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
--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
--
___
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
[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
Complete oversight by me sorry... There was a GID of a group set to 200. After changing that and running sidgen again all the users now have SIDs -- ___ 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
[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
On Mon, Feb 12, 2024 at 10:53:33AM -, Oliver Nixon via FreeIPA-users wrote: > Hi Rob, > > Thanks for confirming. > > The strange thing is there aren't any users outside of the range that I can > find and there is definitely nothing with an ID of 200. It may be a GID of some group. -- Tomasz Torcz Morality must always be based on practicality. to...@pipebreaker.pl — Baron Vladimir Harkonnen -- ___ 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
[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
Just to chime in on this. I'm not 100% this isn't a bug, as I've also hit the same issue after an update. In the end, I've had to re-create the effected accounts with the same UID and GID after deletion, which is resolving the issue for me as I wasn't able to find a solution using the mail-list archives. Marc. -Original Message- From: Oliver Nixon via FreeIPA-users Sent: Monday, February 12, 2024 10:54 AM To: freeipa-users@lists.fedorahosted.org Cc: Oliver Nixon Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working Hi Rob, Thanks for confirming. The strange thing is there aren't any users outside of the range that I can find and there is definitely nothing with an ID of 200. -- ___ 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 -- ___ 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
[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
Hi Rob, Thanks for confirming. The strange thing is there aren't any users outside of the range that I can find and there is definitely nothing with an ID of 200. -- ___ 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
