I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp
How do I track down the cause of this?
-Chip
Schweiss, Chip via FreeIPA-users wrote:
I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp
How do I track down the cause of this?
I don't know how this can happen and don't recall having see it before. To track it down you'd need to enable the audit log in 389-ds on all servers, including any newly created replica and wait for it to be reset. That will show you at least what machine did so. The actual MOD is probably not super interesting but who knows.
rob
On 21/03/2024 18.42, Rob Crittenden via FreeIPA-users wrote:
Schweiss, Chip via FreeIPA-users wrote:
I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp
How do I track down the cause of this?
I don't know how this can happen and don't recall having see it before. To track it down you'd need to enable the audit log in 389-ds on all servers, including any newly created replica and wait for it to be reset. That will show you at least what machine did so. The actual MOD is probably not super interesting but who knows.
For the record, the "modifiersName" operational attribute is useless here. It's always the ipa_pwd_extop plugin:
$ ldapsearch -Y GSSAPI -LLL -b uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName SASL/GSSAPI authentication started SASL username: admin@IPAHCC.TEST SASL SSF: 256 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName: cn=ipa_pwd_extop,cn=plugins,cn=config
Christian
Christian Heimes via FreeIPA-users wrote:
On 21/03/2024 18.42, Rob Crittenden via FreeIPA-users wrote:
Schweiss, Chip via FreeIPA-users wrote:
I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp
How do I track down the cause of this?
I don't know how this can happen and don't recall having see it before. To track it down you'd need to enable the audit log in 389-ds on all servers, including any newly created replica and wait for it to be reset. That will show you at least what machine did so. The actual MOD is probably not super interesting but who knows.
For the record, the "modifiersName" operational attribute is useless here. It's always the ipa_pwd_extop plugin:
$ ldapsearch -Y GSSAPI -LLL -b uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName SASL/GSSAPI authentication started SASL username: admin@IPAHCC.TEST SASL SSF: 256 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName: cn=ipa_pwd_extop,cn=plugins,cn=config
I'm hoping he can correlate the time between the audit change and a connection in the access log which should include the BIND.
rob
Thanks for all the insight. I'll get the audit logging in place before I add any more servers. I have a couple more to do in the next week.
Cheers! -Chip
On Thu, Mar 21, 2024 at 1:03 PM Rob Crittenden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Christian Heimes via FreeIPA-users wrote:
On 21/03/2024 18.42, Rob Crittenden via FreeIPA-users wrote:
Schweiss, Chip via FreeIPA-users wrote:
I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp
How do I track down the cause of this?
I don't know how this can happen and don't recall having see it before. To track it down you'd need to enable the audit log in 389-ds on all servers, including any newly created replica and wait for it to be reset. That will show you at least what machine did so. The actual MOD is probably not super interesting but who knows.
For the record, the "modifiersName" operational attribute is useless here. It's always the ipa_pwd_extop plugin:
$ ldapsearch -Y GSSAPI -LLL -b uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName SASL/GSSAPI authentication started SASL username: admin@IPAHCC.TEST SASL SSF: 256 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=ipahcc,dc=test modifiersName: cn=ipa_pwd_extop,cn=plugins,cn=config
I'm hoping he can correlate the time between the audit change and a connection in the access log which should include the BIND.
rob
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
freeipa-users@lists.fedorahosted.org
-
Christian Heimes -
Rob Crittenden -
Schweiss, Chip