We have a IPA environment that has an existing trust with Active Directory.
I'm trying to troubleshoot some things, and am trying to run a `ldapsearch` against our IPA environment.
It keeps asking for an LDAP Bind password.
1. I know the Directory Admin password
2. I know the local 'admin' password to get into the UI as the "admin" user
3. I know my own Active Directory password.
None of these passwords are working.
[root@cha-cop-lab-mgt-ath-001 whitedm]# ldapsearch -ZZ -H ldap://ipa-hostname-001.lab.example.net -b 'cn=compat,dc=fiberlab,dc=example,dc=net' -D 'cn=whitedm' -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I recall setting up the LDAP password on the initial install of the IPA software when these servers were first launched.
How can I reset this LDAP password?
Not sure I'm sending this to the right place, but here it goes. I inherited a FreeIPA/Identity Manager setup in an enclave (no internet access) environment that is running into problems. There are at least 3 different IdM servers running in the environment spread out across different geographical areas. One of those areas suffered an unschedule power outage recently, and ever since we brought everything back up, the IdM server for this region is having an issue. Please bear with me as I have zero formal experience, training, or real knowledge with IdM.
Logging in to the serverv (it's a VM server, running Centos 7.5), I run "ipactl status" and it shows "Directory Service: STOPPED". I then run "ipactl restart", and things go fine until it gets to "Starting pki-tomcatd Service", where it hangs for quite some time before failing to start and killing all the other services. I check the log at /var/log/pki/pki-tomcat/ca/debug and I see various errors such as (forgive any mistypings, I have to manually type these in as I can't import or screen capure the logs and put them in this message):
"java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid: Invalid certificate: (-8181) Peer's Certificate has expired"
And slightly further down in the same log:
"Cannot reset factory: connections not all returned"
"CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset LDAP connection factory because some connections are still outstanding"
... still further down"
"returnConn:mNumConns now 3 Invalid class name repositorytop"
Assuming I have some weird certificate issue with this server in particular, I try to run a few more commands:
"certutil -L -d /etc/httpd/alias" --> returns a Server-Cert listing with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C for it's attributes. Comparing to a second IdM server in this environment, it seems to be missing a "Signing-Cert"?
I also did a "getcert list", and all certs it has show that they expire in the future (nothing shows as bein currently expired).
I'm confused; it seems to that it is seeing an expired cert *somewhere*, but how do I track down which 'peer' the log file is talking about that has an expired cert? Meanwhile none of the linux clients that point to this IdM server are allowing people to log in/authenticate.
Many thanks for any help!
Yesterday we migrated our dev servers to IPA - to help in the migration, I enabled the allow_all HBAC rule, but despite that, some users get this message:
Jul 29 15:56:23 el4966 sshd: Postponed keyboard-interactive for id094844 from 22.214.171.124 port 35552 ssh2 [preauth]
Jul 29 15:56:49 el4966 sshd: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=el1921.bc user=id094844
Jul 29 15:56:49 el4966 sshd: pam_sss(sshd:auth): received for user id094844: 6 (Permission denied) < ----- This
Jul 29 15:56:52 el4966 sshd: error: PAM: Authentication failure for id094844 from el1921.bc
Jul 29 15:56:52 el4966 sshd: Failed keyboard-interactive/pam for id094844 from 126.96.36.199 port 35552 ssh2
Jul 29 15:56:58 el4966 sshd: Postponed keyboard-interactive for id094844 from 188.8.131.52 port 35552 ssh2 [preauth]
Jul 29 15:57:00 el4966 sshd: Connection closed by 184.108.40.206 port 35552 [preauth]
These are external (AD) users. Weird thing: not all users have this and not everywhere... I tried to remove the LDAP filter on the IPA server -> same thing... I'm running out of ideas...
Thanks for your help!
Sensitivity: Internal Use Only
This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer
I have a FreeIPA setup that trusts an Active Directory domain. I have users who exist in the AD domain, but who are unable to log into Linux systems.
The domains are:
ad.domain.examaple: the Active Directory domain
ipa.ad.domain.example: the FreeIPA domain
The user has a SAM-Account-Name of 'user.name' and a userPrincipalName of
Here are the log messages I see when one of them tries to log in:
==> krb5_child.log <==
(Thu Jul 23 11:08:58 2020) [[sssd[krb5_child]]] [get_and_save_tgt] (0x0020): 1704: [-1765328378][Client 'user.name\@THIRDPARTY.COM(a)IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database]
(Thu Jul 23 11:08:58 2020) [[sssd[krb5_child]]] [map_krb5_error] (0x0020): 1833: [-1765328378][Client 'user.name\@THIRDPARTY.COM(a)IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database]
==> sssd_ipa.ad.domain.example.log <==
(Thu Jul 23 11:08:58 2020) [sssd[be[ipa.ad.domain.example]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
A bit of research brings me to
A UPN suffix has the following restrictions:
It must be the DNS name of a domain, but does not need to be the name of
the domain that contains the user.
It must be the name of a domain in the current domain forest, or an
alternate name listed in the upnSuffixes attribute of the Partitions container
within the Configuration container.
I believe the user account violates the second of these restrictions, in that
its suffix (thirdparty.com) is neither in the AD forest, nor is it found in the
upnSuffixes attribute of
CN=Partitions,CN=Configuration,DC=ad,DC=domain,DC=example in AD.
Now the ugly part. I suspect this is just How Things Are Done around here and
getting the user's userPrincipalName changed to ad.domain.example will not be
So in the meantime, is there any configuration I can do, either on the FreeIPA
servers or on the machine where the user needs to log in, to work around the
UPN suffix mismatch?
I am able to get a TGT for the user with 'kinit user.name(a)AD.DOMAIN.EXAMPLE',
so I guess I'm looking for a hypothetical way to tell sssd to map the UPN
suffix in the user's domain (thirdparty.com) to ad.domain.example when it tries
to get a ticket during user login...
I can also ask to get thirdparty.com added to the AD domain's list of UPN
suffixes. Can anyone confirm whether this would be sufficient to get sssd to be
able to authenticate the user?
Sam Morris <https://robots.org.uk/>
regardless what officially I do, my Centos is not pulling latest FreeiPA binaries to install, it sticks with 4.7
Since everything is working, it is not a deal-breaker, but still, now that everything is stable and config is absolutely correct, it would be time to upgrade and stay up to date with all fixes.
Any help on this topic please? Thanks in advance!