[Freeipa-users] DNS Caching w/ FreeIPA
Hello, How do I manipulate the DNS caching settings in FreeIPA? For example, how do I adjust the cache size, ttl etc ? I'm looking to speed up external queries by caching them in FreeIPA to allow faster lookups on subsequent requests, thereby reducing response times. -- Thx, TK. ___ 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] FreeIPA Migration to RHEL 9 or Cent OS 9 or Alma Linux 9 or Rocky Linux 9
Hey Folks, I'm looking into migrating my FreeIPA 4.6.6 setup to RHEL 9 or any of the subject *nix 9 environments. The immediate steps I can see doing is: 0) Take snapshots 1) Spin up RHEL 9 or Cent OS 9 boxes etc. 2) Install the latest FreeIPA version. 3) Enable replication from the older RHEL 7 FreeIPA 4.6.6 installation to this newer installation. (Possible?) 4) Decomm old nodes or rebuild with latest *nix 9.X image. 5) Rinse and repeat till all done. For step 3) is it even possible to migrate from an older FreeIPA version to a newer one? Any known issues? Should I target the install on the *nix 9 hosts to the exact same version as FreeIPA on RHEL 7 nodes? -- Cheers and Thanks, Tom ___ 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: Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
On 2022-09-26 9:13 a.m., TomK via FreeIPA-users wrote: On 2022-09-26 8:50 a.m., Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: On 2022-09-25 12:42 a.m., TomK via FreeIPA-users wrote: On 2022-09-25 12:38 a.m., TomK via FreeIPA-users wrote: Hey Everyone! Wondering if anyone could help nudge me along in the right direction on this one. Getting the following on my FreeIPA master and replica: Internal Database Error encountered: Could not connect to LDAP server host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) These appeared after some power outages occurred 2-3 times and both hosts were affected. Went over a few pages online to try to get to the bottom of these errors on these VM's however no luck so far: https://access.redhat.com/solutions/3081821 https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ and about a dozen other pages with little luck. Here's what I tried. First, wanted to and did kick off the following on idmipa02: ipa-cacert-manage renew I've read on a few posts that command will cause the running server to become the renewal master, so was cautious to check first: [idmipa01] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz [idmipa02] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz Checked the certs and indeed the serial was different: # ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # pkidbuser, people, ipaca dn: uid=pkidbuser,ou=people,o=ipaca userPassword:: e1NTSEE1MTJ9NUs3N..g4 description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX .MDS.XYZ seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ userCertificate:: MIIDdjCCAl6IYL9mJQXhHIxpc= userCertificate:: MIIDcTCCAlmgAwIBAg.Mdr8SvD9uWfMPwUE4Tf2csf0z+Z userCertificate:: MIIDcTCCAlmgA..yShSmujM9PJrJPBBjLmTCIle9Xl userCertificate:: MIIDdDCCAlygAwIBAg..cgDVlPYm3LmKk+ userstate: 1 usertype: agentType mail: cn: pkidbuser sn: pkidbuser uid: pkidbuser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDdDC..dJmcMKreZ7cgDVlPYm3LmKk+ -END CERTIFICATE- # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' |grep -i serial Serial Number: 268369925 (0xfff0005) So updated it using: ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF dn:uid=pkidbuser,ou=people,o=ipaca changetype: modify replace: description description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX.MDS.XYZ EOF Then verified that only the serial changed (the cert was already in the list anyway so did not need to change) by comparing the before and after: # diff 1.txt 2.txt 11a12,13 description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsyste m,O=NIX.MDS.XYZ 14,15d15 < description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX < .MDS.XYZ Confirmed trust attributes are fine: certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u NIX.MDS.XYZ IPA CA CT,C,C Yet on restart on idmipa02, still the same issue: # ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Failed to restart pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl I have dated snapshots of both servers however, they both are with the above mentioned issue. These hosts were also offline for a couple of months meaning cert expiration could be an issue. Likewise, I could have caused a slight mess myself trying various online solutions that don't always match 100%. In regards to the certificate expiration, below are the expiration dates for various certs though admittedly, I can't be sure of how impacting any of these dates are since I don't yet understand the usage of each of these certs as much as I would like to, which the exception of the subsystemCert: #
[Freeipa-users] Re: Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
On 2022-09-26 8:50 a.m., Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: On 2022-09-25 12:42 a.m., TomK via FreeIPA-users wrote: On 2022-09-25 12:38 a.m., TomK via FreeIPA-users wrote: Hey Everyone! Wondering if anyone could help nudge me along in the right direction on this one. Getting the following on my FreeIPA master and replica: Internal Database Error encountered: Could not connect to LDAP server host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) These appeared after some power outages occurred 2-3 times and both hosts were affected. Went over a few pages online to try to get to the bottom of these errors on these VM's however no luck so far: https://access.redhat.com/solutions/3081821 https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ and about a dozen other pages with little luck. Here's what I tried. First, wanted to and did kick off the following on idmipa02: ipa-cacert-manage renew I've read on a few posts that command will cause the running server to become the renewal master, so was cautious to check first: [idmipa01] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz [idmipa02] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz Checked the certs and indeed the serial was different: # ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # pkidbuser, people, ipaca dn: uid=pkidbuser,ou=people,o=ipaca userPassword:: e1NTSEE1MTJ9NUs3N..g4 description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX .MDS.XYZ seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ userCertificate:: MIIDdjCCAl6IYL9mJQXhHIxpc= userCertificate:: MIIDcTCCAlmgAwIBAg.Mdr8SvD9uWfMPwUE4Tf2csf0z+Z userCertificate:: MIIDcTCCAlmgA..yShSmujM9PJrJPBBjLmTCIle9Xl userCertificate:: MIIDdDCCAlygAwIBAg..cgDVlPYm3LmKk+ userstate: 1 usertype: agentType mail: cn: pkidbuser sn: pkidbuser uid: pkidbuser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDdDC..dJmcMKreZ7cgDVlPYm3LmKk+ -END CERTIFICATE- # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' |grep -i serial Serial Number: 268369925 (0xfff0005) So updated it using: ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF dn:uid=pkidbuser,ou=people,o=ipaca changetype: modify replace: description description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX.MDS.XYZ EOF Then verified that only the serial changed (the cert was already in the list anyway so did not need to change) by comparing the before and after: # diff 1.txt 2.txt 11a12,13 description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsyste m,O=NIX.MDS.XYZ 14,15d15 < description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX < .MDS.XYZ Confirmed trust attributes are fine: certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u NIX.MDS.XYZ IPA CA CT,C,C Yet on restart on idmipa02, still the same issue: # ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Failed to restart pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl I have dated snapshots of both servers however, they both are with the above mentioned issue. These hosts were also offline for a couple of months meaning cert expiration could be an issue. Likewise, I could have caused a slight mess myself trying various online solutions that don't always match 100%. In regards to the certificate expiration, below are the expiration dates for various certs though admittedly, I can't be sure of how impacting any of these dates are since I don't yet understand the usage of each of these certs as much as I would like to, which the exception of the subsystemCert: # getcert list|grep -Ei "expires|status|key pair storage"
[Freeipa-users] Re: Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
On 2022-09-25 12:42 a.m., TomK via FreeIPA-users wrote: On 2022-09-25 12:38 a.m., TomK via FreeIPA-users wrote: Hey Everyone! Wondering if anyone could help nudge me along in the right direction on this one. Getting the following on my FreeIPA master and replica: Internal Database Error encountered: Could not connect to LDAP server host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) These appeared after some power outages occurred 2-3 times and both hosts were affected. Went over a few pages online to try to get to the bottom of these errors on these VM's however no luck so far: https://access.redhat.com/solutions/3081821 https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ and about a dozen other pages with little luck. Here's what I tried. First, wanted to and did kick off the following on idmipa02: ipa-cacert-manage renew I've read on a few posts that command will cause the running server to become the renewal master, so was cautious to check first: [idmipa01] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz [idmipa02] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz Checked the certs and indeed the serial was different: # ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # pkidbuser, people, ipaca dn: uid=pkidbuser,ou=people,o=ipaca userPassword:: e1NTSEE1MTJ9NUs3N..g4 description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX .MDS.XYZ seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ userCertificate:: MIIDdjCCAl6IYL9mJQXhHIxpc= userCertificate:: MIIDcTCCAlmgAwIBAg.Mdr8SvD9uWfMPwUE4Tf2csf0z+Z userCertificate:: MIIDcTCCAlmgA..yShSmujM9PJrJPBBjLmTCIle9Xl userCertificate:: MIIDdDCCAlygAwIBAg..cgDVlPYm3LmKk+ userstate: 1 usertype: agentType mail: cn: pkidbuser sn: pkidbuser uid: pkidbuser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDdDC..dJmcMKreZ7cgDVlPYm3LmKk+ -END CERTIFICATE- # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' |grep -i serial Serial Number: 268369925 (0xfff0005) So updated it using: ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF dn:uid=pkidbuser,ou=people,o=ipaca changetype: modify replace: description description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX.MDS.XYZ EOF Then verified that only the serial changed (the cert was already in the list anyway so did not need to change) by comparing the before and after: # diff 1.txt 2.txt 11a12,13 > description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsyste > m,O=NIX.MDS.XYZ 14,15d15 < description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX < .MDS.XYZ Confirmed trust attributes are fine: certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u NIX.MDS.XYZ IPA CA CT,C,C Yet on restart on idmipa02, still the same issue: # ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Failed to restart pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl I have dated snapshots of both servers however, they both are with the above mentioned issue. These hosts were also offline for a couple of months meaning cert expiration could be an issue. Likewise, I could have caused a slight mess myself trying various online solutions that don't always match 100%. In regards to the certificate expiration, below are the expiration dates for various certs though admittedly, I can't be sure of how impacting any of these dates are since I don't yet understand the usage of each of these certs as much as I would like to, which the exception of the subsystemCert: # getcert list|grep -Ei "expires|status|key pair storage" status: CA_UNREACHABLE key pair s
[Freeipa-users] Re: Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
On 2022-09-25 12:38 a.m., TomK via FreeIPA-users wrote: Hey Everyone! Wondering if anyone could help nudge me along in the right direction on this one. Getting the following on my FreeIPA master and replica: Internal Database Error encountered: Could not connect to LDAP server host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) These appeared after some power outages occurred 2-3 times and both hosts were affected. Went over a few pages online to try to get to the bottom of these errors on these VM's however no luck so far: https://access.redhat.com/solutions/3081821 https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ and about a dozen other pages with little luck. Here's what I tried. First, wanted to and did kick off the following on idmipa02: ipa-cacert-manage renew I've read on a few posts that command will cause the running server to become the renewal master, so was cautious to check first: [idmipa01] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz [idmipa02] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz Checked the certs and indeed the serial was different: # ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # pkidbuser, people, ipaca dn: uid=pkidbuser,ou=people,o=ipaca userPassword:: e1NTSEE1MTJ9NUs3N..g4 description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX .MDS.XYZ seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ userCertificate:: MIIDdjCCAl6IYL9mJQXhHIxpc= userCertificate:: MIIDcTCCAlmgAwIBAg.Mdr8SvD9uWfMPwUE4Tf2csf0z+Z userCertificate:: MIIDcTCCAlmgA..yShSmujM9PJrJPBBjLmTCIle9Xl userCertificate:: MIIDdDCCAlygAwIBAg..cgDVlPYm3LmKk+ userstate: 1 usertype: agentType mail: cn: pkidbuser sn: pkidbuser uid: pkidbuser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDdDC..dJmcMKreZ7cgDVlPYm3LmKk+ -END CERTIFICATE- # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' |grep -i serial Serial Number: 268369925 (0xfff0005) So updated it using: ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF dn:uid=pkidbuser,ou=people,o=ipaca changetype: modify replace: description description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX.MDS.XYZ EOF Then verified that only the serial changed (the cert was already in the list anyway so did not need to change) by comparing the before and after: # diff 1.txt 2.txt 11a12,13 > description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsyste > m,O=NIX.MDS.XYZ 14,15d15 < description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX < .MDS.XYZ Confirmed trust attributes are fine: certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u NIX.MDS.XYZ IPA CA CT,C,C Yet on restart on idmipa02, still the same issue: # ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Failed to restart pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl I have dated snapshots of both servers however, they both are with the above mentioned issue. These hosts were also offline for a couple of months meaning cert expiration could be an issue. Likewise, I could have caused a slight mess myself trying various online solutions that don't always match 100%. In regards to the certificate expiration, below are the expiration dates for various certs though admittedly, I can't be sure of how impacting any of these dates are since I don't yet understand the usage of each of these certs as much as I would like to, which the exception of the subsystemCert: # getcert list|grep -Ei "expires|status|key pair storage" status: C
[Freeipa-users] Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
Hey Everyone! Wondering if anyone could help nudge me along in the right direction on this one. Getting the following on my FreeIPA master and replica: Internal Database Error encountered: Could not connect to LDAP server host idmipa01.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) Internal Database Error encountered: Could not connect to LDAP server host idmipa02.nix.mds.xyz port 636 Error netscape.ldap.LDAPException: Authentication failed (48) These appeared after some power outages occurred 2-3 times and both hosts were affected. Went over a few pages online to try to get to the bottom of these errors on these VM's however no luck so far: https://access.redhat.com/solutions/3081821 https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ and about a dozen other pages with little luck. Here's what I tried. First, wanted to and did kick off the following on idmipa02: ipa-cacert-manage renew I've read on a few posts that command will cause the running server to become the renewal master, so was cautious to check first: [idmipa01] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz [idmipa02] # ipa config-show | grep 'IPA CA renewal master' IPA CA renewal master: idmipa02.nix.mds.xyz Checked the certs and indeed the serial was different: # ldapsearch -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # pkidbuser, people, ipaca dn: uid=pkidbuser,ou=people,o=ipaca userPassword:: e1NTSEE1MTJ9NUs3N..g4 description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX .MDS.XYZ seeAlso: CN=CA Subsystem,O=NIX.MDS.XYZ userCertificate:: MIIDdjCCAl6IYL9mJQXhHIxpc= userCertificate:: MIIDcTCCAlmgAwIBAg.Mdr8SvD9uWfMPwUE4Tf2csf0z+Z userCertificate:: MIIDcTCCAlmgA..yShSmujM9PJrJPBBjLmTCIle9Xl userCertificate:: MIIDdDCCAlygAwIBAg..cgDVlPYm3LmKk+ userstate: 1 usertype: agentType mail: cn: pkidbuser sn: pkidbuser uid: pkidbuser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDdDC..dJmcMKreZ7cgDVlPYm3LmKk+ -END CERTIFICATE- # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'subsystemCert cert-pki-ca' |grep -i serial Serial Number: 268369925 (0xfff0005) So updated it using: ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -W << EOF dn:uid=pkidbuser,ou=people,o=ipaca changetype: modify replace: description description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX.MDS.XYZ EOF Then verified that only the serial changed (the cert was already in the list anyway so did not need to change) by comparing the before and after: # diff 1.txt 2.txt 11a12,13 > description: 2;268369925;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsyste > m,O=NIX.MDS.XYZ 14,15d15 < description: 2;26;CN=Certificate Authority,O=NIX.MDS.XYZ;CN=CA Subsystem,O=NIX < .MDS.XYZ Confirmed trust attributes are fine: certutil -d /etc/dirsrv/slapd-NIX-MDS-XYZ/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u NIX.MDS.XYZ IPA CA CT,C,C Yet on restart on idmipa02, still the same issue: # ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Failed to restart pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl I have dated snapshots of both servers however, they both are with the above mentioned issue. These hosts were also offline for a couple of months meaning cert expiration could be an issue. Likewise, I could have caused a slight mess myself trying various online solutions that don't always match 100%. In regards to the certificate expiration, below are the expiration dates for various certs though admittedly, I can't be sure of how impacting any of these dates are since I don't yet understand the usage of each of these certs as much as I would like to, which the exception of the subsystemCert: # getcert list|grep -Ei "expires|status|key pair storage" status: CA_UNREACHABLE key pair storage:
[Freeipa-users] Re: URL / Host Aliases and CNAME's. How to create custom internal URL's such as http://portal/ -> https://some-very-long-host01.my.long.domain.com/some-excessively-long-url.html
Thanks Peter. I ended up adding the cname in FreeIPA and given the search domains, a link such as the one below, worked fine: http://portal/ Cheers, On 2021-12-20 11:01 p.m., Peter Fern via FreeIPA-users wrote: Typically you fix this on your network, not in DNS, by setting the DNS search suffix via DHCP, so that when a user enters http://portal/ they actually resolve http://portal.yourdomain.com/. On 21/12/21 14:55, TomK via FreeIPA-users wrote: Hello, Wondering, how to create custom internal URL's such as http://portal/ -> https://some-very-long-host01.my.long.domain.com or, ideally: http://portal/ -> https://some-very-long-host01.my.long.domain.com/some-excessively-long-url.html using FreeIPA for internal network resources? I have a CNAME I created. It helps a bit but not fully since the CNAME remains in the URL of the servers and this results in warning about security etc. I effectively just need a redirect alongside the short URL. Looking to see if I can get the equivalent of a customized tiny url effect where I can pick a few short names to use for the internal network resources I want folks to have an easy access too. Examples of a few short names that could be handy on internal networks: http://portal/ http://docs/ http://howto/ http://food/ http://vacation/ etc Not having much luck tweaking my searches online to get what I'm looking for w/ FreeIPA. :( ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Thx, TK. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] URL / Host Aliases and CNAME's. How to create custom internal URL's such as http://portal/ -> https://some-very-long-host01.my.long.domain.com/some-excessively-long-url.html
Hello, Wondering, how to create custom internal URL's such as http://portal/ -> https://some-very-long-host01.my.long.domain.com or, ideally: http://portal/ -> https://some-very-long-host01.my.long.domain.com/some-excessively-long-url.html using FreeIPA for internal network resources? I have a CNAME I created. It helps a bit but not fully since the CNAME remains in the URL of the servers and this results in warning about security etc. I effectively just need a redirect alongside the short URL. Looking to see if I can get the equivalent of a customized tiny url effect where I can pick a few short names to use for the internal network resources I want folks to have an easy access too. Examples of a few short names that could be handy on internal networks: http://portal/ http://docs/ http://howto/ http://food/ http://vacation/ etc Not having much luck tweaking my searches online to get what I'm looking for w/ FreeIPA. :( -- Thx, TK. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: kernel: ns-slapd[5865]: segfault at 5603c0ee2000 ip 00007fe3ba3975ba sp 00007fe3bdbd28a8 error 4 in libc-2.17.so[7fe3ba242000
On 5/19/2020 8:21 AM, Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: Hey All, I've upgrade one side of my two node cluster. However, the secondary won't come even though the manual upgrade apparently went well. [root@idmipa04 ~]# ipa-server-upgrade Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/9]: saving configuration [2/9]: disabling listeners [3/9]: enabling DS global lock [4/9]: disabling Schema Compat [5/9]: starting directory server [6/9]: updating schema [7/9]: upgrading server [8/9]: stopping directory server [9/9]: restoring configuration Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root@idmipa04 ~]# Additional information: [root@idmipa04 ~]# cat /var/log/ipaupgrade.log|tail -n 50 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG duration: 0 seconds 2020-05-19T04:18:10Z DEBUG Done. 2020-05-19T04:18:10Z INFO Update complete 2020-05-19T04:18:10Z INFO Upgrading the configuration of the IPA services 2020-05-19T04:18:10Z DEBUG IPA version 4.6.6-11.el7.centos 2020-05-19T04:18:10Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2020-05-19T04:18:10Z DEBUG Starting external process 2020-05-19T04:18:10Z DEBUG args=/bin/systemctl is-active dirsrv@MWS-MDS-XYZ.service 2020-05-19T04:18:10Z DEBUG Process finished, return code=3 2020-05-19T04:18:10Z DEBUG stdout=unknown 2020-05-19T04:18:10Z DEBUG stderr= 2020-05-19T04:18:10Z DEBUG Starting external process 2020-05-19T04:18:10Z DEBUG args=/bin/systemctl start dirsrv@MWS-MDS-XYZ.service 2020-05-19T04:19:55Z DEBUG Process finished, return code=1 2020-05-19T04:19:55Z DEBUG stdout= 2020-05-19T04:19:55Z DEBUG stderr=Job for dirsrv@MWS-MDS-XYZ.service failed because a fatal signal was delivered to the control process. See "systemctl status dirsrv@MWS-MDS-XYZ.service" and "journalctl -xe" for details. 2020-05-19T04:19:56Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2020-05-19T04:19:56Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2166, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1791, in upgrade_configuration ds.start(ds_serverid) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 656, in start super(DsInstance, self).start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 464, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 136, in start instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 303, in start skip_output=not capture_output) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 563, in run raise CalledProcessError(p.returncode, arg_string, str(output)) 2020-05-19T04:19:56Z DEBUG The ipa-server-upgrade command failed, exception: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 2020-05-19T04:19:56Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 2020-05-19T04:19:56Z ERROR The ipa-server-upgrade command failed. See /var/l
[Freeipa-users] kernel: ns-slapd[5865]: segfault at 5603c0ee2000 ip 00007fe3ba3975ba sp 00007fe3bdbd28a8 error 4 in libc-2.17.so[7fe3ba242000
Hey All, I've upgrade one side of my two node cluster. However, the secondary won't come even though the manual upgrade apparently went well. [root@idmipa04 ~]# ipa-server-upgrade Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/9]: saving configuration [2/9]: disabling listeners [3/9]: enabling DS global lock [4/9]: disabling Schema Compat [5/9]: starting directory server [6/9]: updating schema [7/9]: upgrading server [8/9]: stopping directory server [9/9]: restoring configuration Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root@idmipa04 ~]# Additional information: [root@idmipa04 ~]# cat /var/log/ipaupgrade.log|tail -n 50 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG duration: 0 seconds 2020-05-19T04:18:10Z DEBUG Done. 2020-05-19T04:18:10Z INFO Update complete 2020-05-19T04:18:10Z INFO Upgrading the configuration of the IPA services 2020-05-19T04:18:10Z DEBUG IPA version 4.6.6-11.el7.centos 2020-05-19T04:18:10Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2020-05-19T04:18:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2020-05-19T04:18:10Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2020-05-19T04:18:10Z DEBUG Starting external process 2020-05-19T04:18:10Z DEBUG args=/bin/systemctl is-active dirsrv@MWS-MDS-XYZ.service 2020-05-19T04:18:10Z DEBUG Process finished, return code=3 2020-05-19T04:18:10Z DEBUG stdout=unknown 2020-05-19T04:18:10Z DEBUG stderr= 2020-05-19T04:18:10Z DEBUG Starting external process 2020-05-19T04:18:10Z DEBUG args=/bin/systemctl start dirsrv@MWS-MDS-XYZ.service 2020-05-19T04:19:55Z DEBUG Process finished, return code=1 2020-05-19T04:19:55Z DEBUG stdout= 2020-05-19T04:19:55Z DEBUG stderr=Job for dirsrv@MWS-MDS-XYZ.service failed because a fatal signal was delivered to the control process. See "systemctl status dirsrv@MWS-MDS-XYZ.service" and "journalctl -xe" for details. 2020-05-19T04:19:56Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2020-05-19T04:19:56Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2166, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1791, in upgrade_configuration ds.start(ds_serverid) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 656, in start super(DsInstance, self).start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 464, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 136, in start instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 303, in start skip_output=not capture_output) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 563, in run raise CalledProcessError(p.returncode, arg_string, str(output)) 2020-05-19T04:19:56Z DEBUG The ipa-server-upgrade command failed, exception: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 2020-05-19T04:19:56Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/bin/systemctl start dirsrv@MWS-MDS-XYZ.service' returned non-zero exit status 1 2020-05-19T04:19:56Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root@idmipa04 ~]# [root@idmipa04 ~]# [root@idmipa04 ~]# [root@idmipa04 ~]# [root@idmipa04 ~]# /bin/systemctl start dirsrv@MWS-MDS-XYZ.service
[Freeipa-users] Migrating second IPA server in a two node cluster, to a different VLAN + Masking ipa-client-install password.
Hey All, 1) When moving an IPA Cluster member to another VLAN, is it only necessary to change the member's DNS entries in the primary IPA's DNS config, then change the IP on the secondary's network config? Or is there more steps that would need to be done? 2) Can I join an IPA client to an IPA server using an alternate non-previliged account that has minimal permissions, instead of the admin type account? ipa-client-install --force-join -p admin -w "$TMPP" --fixed-primary --server=$IPA01.$NDOMAIN --server=$IPA02.$NDOMAIN --domain=$NDOMAIN --realm=$UNDOMAIN -U I've created a user with a role that has Host Enrollment and Host Administrators. However, perhaps Host Administrators will give too many permissions, including removal of existing hosts. Wondering if there isn't a more restrictive set of permissions I could give. -- Thx, TK. ___ 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
[Freeipa-users] Re: Users and Admin access for AD Accounts
On 5/3/2020 9:19 AM, Florence Blanc-Renaud via FreeIPA-users wrote: On 5/2/20 2:18 PM, TomK via FreeIPA-users wrote: Hey All, Let's suppose I have two AD groups: unixadmin unixusers In FreeIPA, I would like to give unixadmin group access to ALL FreeIPA functions. Whereas for the unixusers, I would like to give R/O access. I've already done the group mappings from AD to FreeIPA. What is the best way to achieve this? I'm finding related links online but not quite what I'm looking for. I did a test to see if nesting the unixadmin group within the FreeIPA admins group would work but I still can't login to FreeIPA with my AD user, despite my ID residing in the unixadmin group which in turn is nested in the FreeIPA admins group. This is FreeIPA 4.6.4 . Hi, you can find more information in "Configuring and Managing Identity Management" RHEL 8 book, especially in the chapters "Enabling AD users to administer IdM" [1] and "WebUI login for Active DIrectory users" [2]. An AD user needs an id override to be able to login to the WebUI. With this, he will have access to the self-service UI which provides only a limited set of operations on his own account. If the AD user is added to the admins group, he will get additional privileges. HTH, flo Thanks very much Flo! [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_identity_management/index#enabling-ad-user-to-administer-idm_configuring-and-managing-idm [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_identity_management/index#web-ui-login-for-ad-users-login-web-ui-krb ___ 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 -- Thx, TK. ___ 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
[Freeipa-users] Users and Admin access for AD Accounts
Hey All, Let's suppose I have two AD groups: unixadmin unixusers In FreeIPA, I would like to give unixadmin group access to ALL FreeIPA functions. Whereas for the unixusers, I would like to give R/O access. I've already done the group mappings from AD to FreeIPA. What is the best way to achieve this? I'm finding related links online but not quite what I'm looking for. I did a test to see if nesting the unixadmin group within the FreeIPA admins group would work but I still can't login to FreeIPA with my AD user, despite my ID residing in the unixadmin group which in turn is nested in the FreeIPA admins group. This is FreeIPA 4.6.4 . -- Thx, TK. ___ 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
[Freeipa-users] Using sssd/freeipa and samba: User j...@mds.xyz can mount Samba share in Win 10. Same share fails to mount on a Mac using same user.
Hey All,
This might be a bit of an unusual question but perhaps someone here has
seen this scenario.
As per the subject says, user j...@mds.xyz can mount Samba share in Win
10. Same share fails to mount on a Mac using same user.
Appears Mac's insist on interpreting the UPN j...@mds.xyz as
@ instead of just considering the entire string,
"j...@mds.xyz" as a user.
Tried both the Mac UI and command line using such things as:
mount_smbfs -d 5 "//MDS.XYZ;joe:@192.168.0.125/NFS-joe" /samba/
but the attempt fails to mount instead giving:
[2020/02/25 00:38:25.979467, 4] ../source3/smbd/sec_ctx.c:438(pop_sec_ctx)
pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 1
[2020/02/25 00:38:25.979543, 3]
../source3/auth/check_samsec.c:399(check_sam_security)
check_sam_security: Couldn't find user 'joe' in passdb.
[2020/02/25 00:38:25.979614, 2]
../source3/auth/auth.c:334(auth_check_ntlm_password)
check_ntlm_password: Authentication for user [joe] -> [joe] FAILED
with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2020/02/25 00:38:25.979779, 2]
../auth/auth_log.c:476(log_authentication_event_human_readable)
Auth: [SMB2,(null)] user [MDS.XYZ]\[joe] at [Tue, 25 Feb 2020
00:38:25.979710 EST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER]
workstation [MACBOOKPRO-0138] remote host [ipv4:192.168.0.206:52695]
mapped to [MDS.XYZ]\[joe]. local host [ipv4:192.168.0.125:445]
[2020/02/25 00:38:25.980276, 2]
../lib/audit_logging/audit_logging.c:141(audit_log_json)
JSON Authentication: {"timestamp": "2020-02-25T00:38:25.980017-0500",
"type": "Authentication", "Authentication": {"version": {"major": 1,
"minor": 0}, "status": "NT_STATUS_NO_SUCH_USER", "localAddress":
"ipv4:192.168.0.125:445", "remoteAddress": "ipv4:192.168.0.206:52695",
"serviceDescription": "SMB2", "authDescription": null, "clientDomain":
"MDS.XYZ", "clientAccount": "joe", "workstation": "MACBOOKPRO-0138",
"becameAccount": null, "becameDomain": null, "becameSid": null,
"mappedAccount": "joe", "mappedDomain": "MDS.XYZ", "netlogonComputer":
null, "netlogonTrustAccount": null, "netlogonNegotiateFlags":
"0x", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid":
null, "passwordType": "NTLMv2", "duration": 9826}}
[2020/02/25 00:38:25.980420, 4] ../source3/smbd/sec_ctx.c:438(pop_sec_ctx)
SSSD is configured on the NFS03 servers from which Samba is running.
Authentication works fine on all hosts with SSSD. SSSD in turn is
connected to FreeIPA.
Wondering if anyone has seen this scenario and remembers what the
possible solution may have been to get said mounts working on a Mac?
--
Thx,
TK.
___
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
[Freeipa-users] Re: FreeIPA / SSSD and IPV6
On 12/6/2019 10:51 AM, TomK wrote: On 12/4/2019 11:16 AM, Alexander Bokovoy via FreeIPA-users wrote: On ke, 04 joulu 2019, Stephen John Smoogen via FreeIPA-users wrote: On Tue, 3 Dec 2019 at 21:43, TomK via FreeIPA-users wrote: Hey All, Does FreeIPA fully support IPV6 or are there corner cases and limitations that could make it a show stopper? Can you define 'fully support' IPV6? I say this from seeing various IT groups still having to deal with major network hardware vendors saying they 'fully support IPV6' but still needing weekly firmware updates because of switch crashes due to IPv6 options. And the problem seems to be that the IPV6 spec is complex and spread out over multiple documents with parts implemented from draft documents that never got out of committee. At times I doubt anything fully supports IPv6 so it is better to come up with what you mean by what you need IPv6 support to do and work from there. Yep. On the other hand, FreeIPA does have few open IPv6-related problems at the moment. It is known to work in the most IPv6 environments we have seen so far but there are management issues in DNS handling, for example. https://pagure.io/freeipa/issue/5658 https://pagure.io/freeipa/issue/4674 Whether these issues prevent you to deploy FreeIPA in IPv6-only environment is up to you. Thanks everyone. What I mean by 'fully supported' is just as the subject says, the FreeIPA piece. To clarify a bit further I'll break this down into two parts: 1) FreeIPA Core Project: Let's assume for the sake of this discussion that the OS, Hardware and what not fully supports IPv6. So in other words, anything outside the realm of what you control or code within the FreeIPA project is out of scope of this question. 2) Integration: FreeIPA / SSSD will integrate with a host of technologies including SSSD, 389 Directory Server etc. If any of those components aren't ready and impact FreeIPA components, I would be interested to know. + Subject change to include SSSD folks. Remembered just now meant to ask the SSSD community as well. So therefore a third question as well: 3) SSSD Core Project: Same as question 1 above but for SSSD. -- Thx, TK. ___ 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
[Freeipa-users] Re: FreeIPA and IPV6
On 12/4/2019 11:16 AM, Alexander Bokovoy via FreeIPA-users wrote: On ke, 04 joulu 2019, Stephen John Smoogen via FreeIPA-users wrote: On Tue, 3 Dec 2019 at 21:43, TomK via FreeIPA-users wrote: Hey All, Does FreeIPA fully support IPV6 or are there corner cases and limitations that could make it a show stopper? Can you define 'fully support' IPV6? I say this from seeing various IT groups still having to deal with major network hardware vendors saying they 'fully support IPV6' but still needing weekly firmware updates because of switch crashes due to IPv6 options. And the problem seems to be that the IPV6 spec is complex and spread out over multiple documents with parts implemented from draft documents that never got out of committee. At times I doubt anything fully supports IPv6 so it is better to come up with what you mean by what you need IPv6 support to do and work from there. Yep. On the other hand, FreeIPA does have few open IPv6-related problems at the moment. It is known to work in the most IPv6 environments we have seen so far but there are management issues in DNS handling, for example. https://pagure.io/freeipa/issue/5658 https://pagure.io/freeipa/issue/4674 Whether these issues prevent you to deploy FreeIPA in IPv6-only environment is up to you. Thanks everyone. What I mean by 'fully supported' is just as the subject says, the FreeIPA piece. To clarify a bit further I'll break this down into two parts: 1) FreeIPA Core Project: Let's assume for the sake of this discussion that the OS, Hardware and what not fully supports IPv6. So in other words, anything outside the realm of what you control or code within the FreeIPA project is out of scope of this question. 2) Integration: FreeIPA / SSSD will integrate with a host of technologies including SSSD, 389 Directory Server etc. If any of those components aren't ready and impact FreeIPA components, I would be interested to know. -- Thx, TK. ___ 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
[Freeipa-users] ipa-client password
Hey All, Given a line like this: ipa-client-install --force-join -p admin -w "*" --fixed-primary --server=idmipa01.nix.mds.xyz --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U 1) Is there a way to pull the password from a safe store before passing it in or pull from a safe store directly? or 2) Can I specify an unprevilidged user to register with? or 3) Register without the use of a password? Looking to register clients in ways that don't reveal any account passwords with which the registration has occurred with. -- Thx, TK. ___ 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
[Freeipa-users] Re: NFS Home directories: ipa-client-automount on Ubuntu 18.04
Just added this line to nsswitch.conf and things are working fine despite the errors below: root@xoa-org01:/n/dom.lab/user# grep -Ei auto /etc/nsswitch.conf automount: files sss root@xoa-org01:/n/dom.lab/user# Guessing the messages were not fatal. Thx, TK On 10/19/2019 8:01 PM, TomK via FreeIPA-users wrote: Hey All, Are there any recent instructions available for configuring NFS home directories using ipa-client-automount ? Currently above command generates: stderr= Started rpcidmapd Starting external process args=['/bin/systemctl', 'enable', 'nfs-idmapd.service'] Process finished, return code=0 stdout= stderr=The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. stderr= Started rpcgssd Starting external process args=['/bin/systemctl', 'enable', 'rpc-gssd.service'] Process finished, return code=0 stdout= stderr=The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. And mount doesn't work. -- Thx, TK. ___ 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
[Freeipa-users] NFS Home directories: ipa-client-automount on Ubuntu 18.04
Hey All, Are there any recent instructions available for configuring NFS home directories using ipa-client-automount ? Currently above command generates: stderr= Started rpcidmapd Starting external process args=['/bin/systemctl', 'enable', 'nfs-idmapd.service'] Process finished, return code=0 stdout= stderr=The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. stderr= Started rpcgssd Starting external process args=['/bin/systemctl', 'enable', 'rpc-gssd.service'] Process finished, return code=0 stdout= stderr=The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. And mount doesn't work. -- Thx, TK. ___ 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
[Freeipa-users] Re: kadmin principal for an IPA master, but not for slave.
On 8/22/2019 2:46 AM, Alexander Bokovoy via FreeIPA-users wrote:
On ke, 21 elo 2019, TomK via FreeIPA-users wrote:
Hey All,
The primary master I have has the kadmin principal for it:
kadmin/ipa03.mws.mds@mws.mds.xyz
The slave (idmipa04) doesn't have a corresponding kadmin/... principal
entry. Can't find these principals in the UI.
It is only created on the first master because it is part of the process
that is run within 'kdb5_util create'. This process is not run on
replica deployment because we already have all the needed master keys
and the database layout.
We don't really use KADMIN protocol over network in FreeIPA, so this
principal is rather unutilized.
1) Should the slave installer have created the slave kadmin/...
principal?
2) If I wanted to create one, should the pass be any random string or
something specific?
3) Are there specific IPA commands to create the kadmin/... principals
with?
What do you need it for? What operations do you miss from FreeIPA
CLI/API?
I'm getting the following on the IPA KDC that I'm tying to a VIP. The
VIP is handled by HAproxy and is meant to provide redundancy in case of
failure in a single IPA node without having to reconfigure servers for a
new IP:
[root@idmipa03 ~]# tail -f /var/log/krb5kdc.log
Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11
Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime
1566441372, etypes {rep=18 tkt=18 ses=18},
HTTP/idmipa03.mws.mds@mws.mds.xyz for
ldap/idmipa03.mws.mds@mws.mds.xyz
Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): ...
CONSTRAINED-DELEGATION s4u-client=cmadmin-53002...@mws.mds.xyz
Aug 21 22:36:14 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: SERVER_NOT_FOUND:
cmadmin-53002...@mws.mds.xyz for
kadmin/idmipa04.mws.mds@mws.mds.xyz, Server not found in Kerberos
database
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5616](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: NEEDED_PREAUTH:
cmadmin-53002...@mws.mds.xyz for kadmin/ad...@mws.mds.xyz, Additional
pre-authentication required
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5616](info): closing down fd 11
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime
1566441376, etypes {rep=18 tkt=18 ses=18}, cmadmin-53002...@mws.mds.xyz
for kadmin/ad...@mws.mds.xyz
Aug 21 22:36:16 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11
Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5617](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: NEEDED_PREAUTH:
cmadmin-53002...@mws.mds.xyz for krbtgt/mws.mds@mws.mds.xyz,
Additional pre-authentication required
Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5617](info): closing down fd 11
Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5618](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime
1566441500, etypes {rep=18 tkt=18 ses=18}, cmadmin-53002...@mws.mds.xyz
for krbtgt/mws.mds@mws.mds.xyz
Aug 21 22:38:20 idmipa03.mws.mds.xyz krb5kdc[5618](info): closing down fd 11
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.134: ISSUE: authtime
1566441500, etypes {rep=18 tkt=18 ses=18}, cmadmin-53002...@mws.mds.xyz
for HTTP/idmipa03.mws.mds@mws.mds.xyz
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime
1566441500, etypes {rep=18 tkt=18 ses=18},
HTTP/idmipa03.mws.mds@mws.mds.xyz for
ldap/idmipa03.mws.mds@mws.mds.xyz
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ...
CONSTRAINED-DELEGATION s4u-client=cmadmin-53002...@mws.mds.xyz
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.0.154: ISSUE: authtime
1566441500, etypes {rep=18 tkt=18 ses=18},
HTTP/idmipa03.mws.mds@mws.mds.xyz for
ldap/idmipa03.mws.mds@mws.mds.xyz
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): ...
CONSTRAINED-DELEGATION s4u-client=cmadmin-53002...@mws.mds.xyz
Aug 21 22:38:21 idmipa03.mws.mds.xyz krb5kdc[5619](info): closing down fd 11
The message that appears in the client is:
+ kadmin -k -t /tmp/cmf9215806201763456498.keytab -p
cmadmin-53002...@mws.mds.xyz -r MWS.MDS.XYZ -q 'modprinc -maxrenewlife
"432000 sec" hue/cm-r01en02.mws.mds@mws.mds.xyz'
kadmin: Communication failure with server while initializing kadmin
interface
[Freeipa-users] kadmin principal for an IPA master, but not for slave.
Hey All, The primary master I have has the kadmin principal for it: kadmin/ipa03.mws.mds@mws.mds.xyz The slave (idmipa04) doesn't have a corresponding kadmin/... principal entry. Can't find these principals in the UI. 1) Should the slave installer have created the slave kadmin/... principal? 2) If I wanted to create one, should the pass be any random string or something specific? 3) Are there specific IPA commands to create the kadmin/... principals with? Thx for taking a look. -- Thx, TK. ___ 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
[Freeipa-users] IPAM that integrates well with FreeIPA
Hey Guy's, I'm looking for an IPAM (IP Address Management) tool that will integrate with FreeIPA to provide: 1) IP Management 2) Provides DHCP 3) *Integrates well with FreeIPA* Many of the tools I saw provide conflicting capabilities. Would be great if the IPAM tool checked FreeIPA to see if the IP is already used. Has anyone come across such a tool and tried it with FreeIPA? -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Two distinct IPA server clusters:
Hey All, Given that I have two separate IPA clusters on the same subnet but two different domains, is there any chance that the IPA servers can issue identical UID / GID numbers thereby causing conflicts on the setup? When setting up the IPA servers, is there a change the same ID range can be given to each separate IPA cluster? The two IPA clusters are independent of each other (not replicas of each other) and are only authoritative for their two separate domains. Example ID ranges of off the primaries of the two clusters: Cluster A [ ipa01 / 02 ] # ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 15560 Number of IDs in the range: 20 First RID of the corresponding RID range: 15560 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory domain range Range name: A.ABC.123_id_range First Posix ID of the range: 174660 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 # Cluster B [ ipa03 / 04 ] # ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 15560 Number of IDs in the range: 20 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory domain range Range name: B.ABC.123_id_range First Posix ID of the range: 116340 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 # -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Recreating a VM with same host name and re-registering it with FreeIPA
On 2/24/2019 4:53 AM, Alexander Bokovoy via FreeIPA-users wrote: On la, 23 helmi 2019, TomK via FreeIPA-users wrote: On 2/22/2019 9:51 AM, Alexander Bokovoy via FreeIPA-users wrote: On Fri, 22 Feb 2019, TomK via FreeIPA-users wrote: On 2/20/2019 10:58 PM, TomK wrote: On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: Hey All, Getting a scenario where the hostname doesn't resolve to the new IP if the VM is recreated multiple times against an IPA server. I've tried clearing the caches on the clients but no luck.?? I have to allow a specific amount of time to pass before I can use the DNS name that now points to a different (new) IP that was assigned via DHCP. This apparently also impacts the automounter and it won't work until much later either.?? I won't be able to use the NFS mount configured until then.?? On initial login users need to wait about 5 minutes before they can login with home folder set to / instead as a result: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Creating home directory for abc.123\sam. Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: No such file or directory -sh-4.2$ Has anyone seen this scenario before and have a general high level idea where I could start to poke??? Seems to me like a DNS Cache Refresh or Timeout but not sure about the specifics. /n/abc.123/sam exists and mount works off of other hosts that have been around for a while. I'd guess it is the DNS TTL. You'd need to lower that in the DNS server. I assume this is some sort of dev or qe box that is re-provisioned frequently? That's correct. Fixed. At least the above immediate issue. Ended up restarting the client and the NFS services on the NFS cluster one by one. I notice now as well that the ID assigned to AD users has changed in the latest versions of SSSD / IPA. The UNIX Attributes that were always set in the AD DC are now being respected: OLD SSSD / IPA: # id sam@abc.123 uid=155601104(sam@abc.123) / gid=155601107(nixgrp@abc.123) NEW SSSD / IPA: # id sam@abc.123 uid=1(sam@abc.123) / gid=1(nixgrp@abc.123) @abc.123) This is probably due to you not forcing a specific ID range type when creating the trust so it picked up what was able to autodetect, eg. posix attributes in AD. Would the ID's on the old IPA / SSSD setup be retained if the old IPA cluster were to be upgraded? The change only applies when you are removing trust to AD and existing ID ranges. Otherwise it should not change at all. Show your 'ipa idrange-find' output. Yes. Different ranges exist: [root@ipa03 ~]# ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 1 Number of IDs in the range: 20 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory trust range with POSIX attributes Range name: B.ABC.123_id_range First Posix ID of the range: 116340 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 [root@ipa03 ~]# Older cluster: [root@ipa01 ~]# ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 15560 Number of IDs in the range: 20 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory domain range Range name: A.ABC.123_id_range First Posix ID of the range: 174660 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 [root@ipa01 ~]# I did try to modify the baseID using: ipa idrange-mod ABC.123_id_range --base-id 15560 and [root@ipa03 ~]# ldapmodify -H ldapi://%2fvar%2frun%2fslapd-B-ABC-123.socket << EOF dn: cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123 changetype: modify replace: ipabaserid ipabaserid: 15560 - replace: ipaBaseID ipaBaseID: 15560 - replace: ipaIDRangeSize ipaIDRangeSize: 20 - replace: ipaNTTrustedDomainSID ipaNTTrustedDomainSID: S-1-5-21-1803828911-4163023034-2461700517 - replace: ipaRangeType ipaRangeType: ipa-ad-trust-posix - EOF SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123" [root@ipa03 ~]# but even though the number changed, it still shows the earlier 1 ID for sam@abc.123. So I'm missing something.
[Freeipa-users] Re: Recreating a VM with same host name and re-registering it with FreeIPA
On 2/22/2019 9:51 AM, Alexander Bokovoy via FreeIPA-users wrote: On Fri, 22 Feb 2019, TomK via FreeIPA-users wrote: On 2/20/2019 10:58 PM, TomK wrote: On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: Hey All, Getting a scenario where the hostname doesn't resolve to the new IP if the VM is recreated multiple times against an IPA server. I've tried clearing the caches on the clients but no luck.?? I have to allow a specific amount of time to pass before I can use the DNS name that now points to a different (new) IP that was assigned via DHCP. This apparently also impacts the automounter and it won't work until much later either.?? I won't be able to use the NFS mount configured until then.?? On initial login users need to wait about 5 minutes before they can login with home folder set to / instead as a result: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Creating home directory for abc.123\sam. Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: No such file or directory -sh-4.2$ Has anyone seen this scenario before and have a general high level idea where I could start to poke??? Seems to me like a DNS Cache Refresh or Timeout but not sure about the specifics. /n/abc.123/sam exists and mount works off of other hosts that have been around for a while. I'd guess it is the DNS TTL. You'd need to lower that in the DNS server. I assume this is some sort of dev or qe box that is re-provisioned frequently? That's correct. Fixed. At least the above immediate issue. Ended up restarting the client and the NFS services on the NFS cluster one by one. I notice now as well that the ID assigned to AD users has changed in the latest versions of SSSD / IPA. The UNIX Attributes that were always set in the AD DC are now being respected: OLD SSSD / IPA: # id sam@abc.123 uid=155601104(sam@abc.123) / gid=155601107(nixgrp@abc.123) NEW SSSD / IPA: # id sam@abc.123 uid=1(sam@abc.123) / gid=1(nixgrp@abc.123) @abc.123) This is probably due to you not forcing a specific ID range type when creating the trust so it picked up what was able to autodetect, eg. posix attributes in AD. Would the ID's on the old IPA / SSSD setup be retained if the old IPA cluster were to be upgraded? The change only applies when you are removing trust to AD and existing ID ranges. Otherwise it should not change at all. Show your 'ipa idrange-find' output. Yes. Different ranges exist: [root@ipa03 ~]# ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 1 Number of IDs in the range: 20 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory trust range with POSIX attributes Range name: B.ABC.123_id_range First Posix ID of the range: 116340 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 [root@ipa03 ~]# Older cluster: [root@ipa01 ~]# ipa idrange-find 2 ranges matched Range name: ABC.123_id_range First Posix ID of the range: 15560 Number of IDs in the range: 20 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-1803828911-4163023034-2461700517 Range type: Active Directory domain range Range name: A.ABC.123_id_range First Posix ID of the range: 174660 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range Number of entries returned 2 [root@ipa01 ~]# I did try to modify the baseID using: ipa idrange-mod ABC.123_id_range --base-id 15560 and [root@ipa03 ~]# ldapmodify -H ldapi://%2fvar%2frun%2fslapd-B-ABC-123.socket << EOF > dn: cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123 > changetype: modify > replace: ipabaserid > ipabaserid: 15560 > - > replace: ipaBaseID > ipaBaseID: 15560 > - > replace: ipaIDRangeSize > ipaIDRangeSize: 20 > - > replace: ipaNTTrustedDomainSID > ipaNTTrustedDomainSID: S-1-5-21-1803828911-4163023034-2461700517 > - > replace: ipaRangeType > ipaRangeType: ipa-ad-trust-posix > - > EOF SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=ABC.123_id_range,cn=ranges,cn=etc,dc=b,dc=abc,dc=123" [root@ipa03 ~]# but even though the number changed, it still shows the earlier 1 ID for sam@abc.123. So I'm missing something. Checked
[Freeipa-users] Re: Recreating a VM with same host name and re-registering it with FreeIPA
On 2/20/2019 10:58 PM, TomK wrote: On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: Hey All, Getting a scenario where the hostname doesn't resolve to the new IP if the VM is recreated multiple times against an IPA server. I've tried clearing the caches on the clients but no luck. I have to allow a specific amount of time to pass before I can use the DNS name that now points to a different (new) IP that was assigned via DHCP. This apparently also impacts the automounter and it won't work until much later either. I won't be able to use the NFS mount configured until then. On initial login users need to wait about 5 minutes before they can login with home folder set to / instead as a result: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Creating home directory for abc.123\sam. Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: No such file or directory -sh-4.2$ Has anyone seen this scenario before and have a general high level idea where I could start to poke? Seems to me like a DNS Cache Refresh or Timeout but not sure about the specifics. /n/abc.123/sam exists and mount works off of other hosts that have been around for a while. I'd guess it is the DNS TTL. You'd need to lower that in the DNS server. I assume this is some sort of dev or qe box that is re-provisioned frequently? That's correct. Fixed. At least the above immediate issue. Ended up restarting the client and the NFS services on the NFS cluster one by one. I notice now as well that the ID assigned to AD users has changed in the latest versions of SSSD / IPA. The UNIX Attributes that were always set in the AD DC are now being respected: OLD SSSD / IPA: # id sam@abc.123 uid=155601104(sam@abc.123) / gid=155601107(nixgrp@abc.123) NEW SSSD / IPA: # id sam@abc.123 uid=1(sam@abc.123) / gid=1(nixgrp@abc.123) @abc.123) Mentioning since the new issue is now as follows when trying to use the same NFS cluster with a second IPA cluster: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Last login: Thu Feb 21 07:55:12 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: Permission denied -sh: /n/abc.123/sam/.profile: Permission denied -sh-4.2$ Would the ID's on the old IPA / SSSD setup be retained if the old IPA cluster were to be upgraded? -- Cheers, Tom K. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Recreating a VM with same host name and re-registering it with FreeIPA
On 2/20/2019 10:13 PM, Rob Crittenden via FreeIPA-users wrote: TomK via FreeIPA-users wrote: Hey All, Getting a scenario where the hostname doesn't resolve to the new IP if the VM is recreated multiple times against an IPA server. I've tried clearing the caches on the clients but no luck. I have to allow a specific amount of time to pass before I can use the DNS name that now points to a different (new) IP that was assigned via DHCP. This apparently also impacts the automounter and it won't work until much later either. I won't be able to use the NFS mount configured until then. On initial login users need to wait about 5 minutes before they can login with home folder set to / instead as a result: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Creating home directory for abc.123\sam. Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: No such file or directory -sh-4.2$ Has anyone seen this scenario before and have a general high level idea where I could start to poke? Seems to me like a DNS Cache Refresh or Timeout but not sure about the specifics. /n/abc.123/sam exists and mount works off of other hosts that have been around for a while. I'd guess it is the DNS TTL. You'd need to lower that in the DNS server. I assume this is some sort of dev or qe box that is re-provisioned frequently? That's correct. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Recreating a VM with same host name and re-registering it with FreeIPA
Hey All, Getting a scenario where the hostname doesn't resolve to the new IP if the VM is recreated multiple times against an IPA server. I've tried clearing the caches on the clients but no luck. I have to allow a specific amount of time to pass before I can use the DNS name that now points to a different (new) IP that was assigned via DHCP. This apparently also impacts the automounter and it won't work until much later either. I won't be able to use the NFS mount configured until then. On initial login users need to wait about 5 minutes before they can login with home folder set to / instead as a result: Using username "abc.123\sam". Using keyboard-interactive authentication. Password: Creating home directory for abc.123\sam. Last login: Wed Feb 20 02:39:18 2019 from 192.168.0.76 Could not chdir to home directory /n/abc.123/sam: No such file or directory -sh-4.2$ Has anyone seen this scenario before and have a general high level idea where I could start to poke? Seems to me like a DNS Cache Refresh or Timeout but not sure about the specifics. /n/abc.123/sam exists and mount works off of other hosts that have been around for a while. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: getent group doesn't show private group on one IPA server, but does on another.
On 2/18/2019 4:25 AM, Sumit Bose via FreeIPA-users wrote: On Sun, Feb 17, 2019 at 07:43:33PM -0500, TomK via FreeIPA-users wrote: On 2/17/2019 2:19 PM, Alexander Bokovoy via FreeIPA-users wrote: On Sun, 17 Feb 2019, TomK via FreeIPA-users wrote: Hey All, Scenario: Two IPA clusters, both with a unique trust to the same AD DC. One picks up the private group, the other doesn't. I can login with the AD user to both: IPA Cluster 1 (ipa01, ipa02) - a.abc.123 # getent group alex@abc.123 alex@abc.123:*:155601104: # IPA Cluster 2 (ipa03, ipa04) - b.abc.123 # getent group alex@abc.123 # Curious if anyone ran into the above before and is willing to throw in a hint or two? Would be appreciated. You need to start with standard debugging technique for this case: - get SSSD debug level set for a domain and nss section on IPA master used for resolution requests - issue your request - collect sssd logs and see what happens If you have it working on IPA master but not on IPA client, gather the same amount of logs on both IPA client and IPA master from the same time frame. SSSD troubleshooting page is https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html Thanks Alex. Aware but just have the snippet for now. Was going to take a few quick tips and then dig through the logs myself later. Nontheless, suspect it's selinux being enabled when it was being installed. I may blow away the cluster and rebuild if fixing things will take longer. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [get_client_cred] (0x4000): Client creds: euid[994] egid[990] pid[15730]. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [accept_fd_handler] (0x0020): Access denied for uid [994]. You can ignore this. SSSD's authdata plugin called from inside 389ds tries to send the PAC of the current DS user to SSSD's PAC responder to process the group membership. ==> sssd_nss.log <== (Sun Feb 17 18:46:19 2019) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[16473]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55e2be292510][21] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [nss_getby_name] (0x0400): Input name: alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #97: Setting "Group by name" plugin (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_send] (0x0400): CR #97: New request 'Group by name' (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_process_input] (0x0400): CR #97: Parsing input name [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'alex@abc.123' matched expression for domain 'abc.123', user is alex (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_name] (0x0400): CR #97: Setting name [alex] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #97: Performing a single domain search (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #97: Search will check the cache and check the data provider (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain abc.123 type POSIX is valid (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #97: Using domain [abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #97: Preparing input data for domain [abc.123] rules (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_send] (0x0400): CR #97: Looking up alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: Checking negative cache for [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/GROUP/abc.123/alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: [alex@abc.123] is not present in negative cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #97: Looking up [alex@abc.123] in cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55e2be29b240 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55e2be295ce0 (Sun Feb 17 18:46:19 2019) [sssd[nss]]
[Freeipa-users] Re: getent group doesn't show private group on one IPA server, but does on another.
On 2/17/2019 7:43 PM, TomK via FreeIPA-users wrote: On 2/17/2019 2:19 PM, Alexander Bokovoy via FreeIPA-users wrote: On Sun, 17 Feb 2019, TomK via FreeIPA-users wrote: Hey All, Scenario: Two IPA clusters, both with a unique trust to the same AD DC. One picks up the private group, the other doesn't. I can login with the AD user to both: IPA Cluster 1 (ipa01, ipa02) - a.abc.123 # getent group alex@abc.123 alex@abc.123:*:155601104: # IPA Cluster 2 (ipa03, ipa04) - b.abc.123 # getent group alex@abc.123 # Curious if anyone ran into the above before and is willing to throw in a hint or two? Would be appreciated. You need to start with standard debugging technique for this case: - get SSSD debug level set for a domain and nss section on IPA master used for resolution requests - issue your request - collect sssd logs and see what happens If you have it working on IPA master but not on IPA client, gather the same amount of logs on both IPA client and IPA master from the same time frame. SSSD troubleshooting page is https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html Thanks Alex. Aware but just have the snippet for now. Was going to take a few quick tips and then dig through the logs myself later. Nontheless, suspect it's selinux being enabled when it was being installed. I may blow away the cluster and rebuild if fixing things will take longer. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [get_client_cred] (0x4000): Client creds: euid[994] egid[990] pid[15730]. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [accept_fd_handler] (0x0020): Access denied for uid [994]. # id 994 uid=994(dirsrv) gid=990(dirsrv) groups=990(dirsrv) ==> sssd_nss.log <== (Sun Feb 17 18:46:19 2019) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[16473]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55e2be292510][21] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [nss_getby_name] (0x0400): Input name: alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #97: Setting "Group by name" plugin (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_send] (0x0400): CR #97: New request 'Group by name' (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_process_input] (0x0400): CR #97: Parsing input name [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'alex@abc.123' matched expression for domain 'abc.123', user is alex (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_name] (0x0400): CR #97: Setting name [alex] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #97: Performing a single domain search (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #97: Search will check the cache and check the data provider (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain abc.123 type POSIX is valid (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #97: Using domain [abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #97: Preparing input data for domain [abc.123] rules (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_send] (0x0400): CR #97: Looking up alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: Checking negative cache for [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/GROUP/abc.123/alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: [alex@abc.123] is not present in negative cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #97: Looking up [alex@abc.123] in cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55e2be29b240 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55e2be295ce0 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Running timer event 0x55e2be29b240 "ltdb_callback" (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0
[Freeipa-users] Re: getent group doesn't show private group on one IPA server, but does on another.
On 2/17/2019 2:19 PM, Alexander Bokovoy via FreeIPA-users wrote: On Sun, 17 Feb 2019, TomK via FreeIPA-users wrote: Hey All, Scenario: Two IPA clusters, both with a unique trust to the same AD DC. One picks up the private group, the other doesn't. I can login with the AD user to both: IPA Cluster 1 (ipa01, ipa02) - a.abc.123 # getent group alex@abc.123 alex@abc.123:*:155601104: # IPA Cluster 2 (ipa03, ipa04) - b.abc.123 # getent group alex@abc.123 # Curious if anyone ran into the above before and is willing to throw in a hint or two? Would be appreciated. You need to start with standard debugging technique for this case: - get SSSD debug level set for a domain and nss section on IPA master used for resolution requests - issue your request - collect sssd logs and see what happens If you have it working on IPA master but not on IPA client, gather the same amount of logs on both IPA client and IPA master from the same time frame. SSSD troubleshooting page is https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html Thanks Alex. Aware but just have the snippet for now. Was going to take a few quick tips and then dig through the logs myself later. Nontheless, suspect it's selinux being enabled when it was being installed. I may blow away the cluster and rebuild if fixing things will take longer. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [get_client_cred] (0x4000): Client creds: euid[994] egid[990] pid[15730]. (Sun Feb 17 18:46:19 2019) [sssd[pac]] [accept_fd_handler] (0x0020): Access denied for uid [994]. ==> sssd_nss.log <== (Sun Feb 17 18:46:19 2019) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[16473]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55e2be292510][21] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Sun Feb 17 18:46:19 2019) [sssd[nss]] [nss_getby_name] (0x0400): Input name: alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR #97: Setting "Group by name" plugin (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_send] (0x0400): CR #97: New request 'Group by name' (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_process_input] (0x0400): CR #97: Parsing input name [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'alex@abc.123' matched expression for domain 'abc.123', user is alex (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_name] (0x0400): CR #97: Setting name [alex] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #97: Performing a single domain search (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain b.abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_domain_get_state] (0x1000): Domain abc.123 is Active (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #97: Search will check the cache and check the data provider (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain abc.123 type POSIX is valid (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #97: Using domain [abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #97: Preparing input data for domain [abc.123] rules (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_send] (0x0400): CR #97: Looking up alex@abc.123 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: Checking negative cache for [alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/GROUP/abc.123/alex@abc.123] (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #97: [alex@abc.123] is not present in negative cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #97: Looking up [alex@abc.123] in cache (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55e2be29b240 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55e2be295ce0 (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Running timer event 0x55e2be29b240 "ltdb_callback" (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x55e2be295ce0 "ltdb_timeout" (Sun Feb 17 18:46:19 2019) [sssd[nss]] [ldb] (0x4000): E
[Freeipa-users] Re: Replica creation using 'ipa-replica-prepare' to generate replica file,is supported only in 0-level IPA domain.
On 2/6/2019 4:12 AM, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/6/19 6:03 AM, TomK via FreeIPA-users wrote: On 2/5/2019 5:12 AM, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/5/19 8:15 AM, TomK via FreeIPA-users wrote: Hello, Would someone please point me to a concise list of steps I can use here? Running 1.) and 2.) yields various errors and I would like to try a known set of working commands to get a replica going in this state before posting with errors: # ipa-replica-prepare ipa04.abc.xyz.123 --ip-address 192.168.0.20 -p "PASS01" Replica creation using 'ipa-replica-prepare' to generate replica file is supported only in 0-level IPA domain. The current IPA domain level is 1 and thus the replica must be created by promoting an existing IPA client. To set up a replica use the following procedure: 1.) set up a client on the host using 'ipa-client-install' 2.) promote the client to replica running 'ipa-replica-install' *without* replica file specified 'ipa-replica-prepare' is allowed only in domain level 0 The ipa-replica-prepare command failed. Hi, the process to install a replica has evolved since IPA 4.3. If your master was installed with IPA 4.3+, then it is using domain level 1 by default (unless you specified ipa-server-install --domain-level 0 during the installation). In this case, please refer to this wiki [1] to install a replica. There is no need to create a replica file, and you can either: - install the future replica as a client with: $ ipa-client-install [options] then run ipa-replica-install to promote the machine from client to replica using: $ kinit admin $ ipa-replica-install or - directly install the replica using: $ ipa-replica-install --principal admin --admin-password xx [options] Thanks Florence! To add some background to the conversation, I ran into the following when trying just those commands: 1) Running ipa-replica-install reported errors if both the master and replica DNS entries did not appear in the master's zone / reverse files. Had to add them manually. The hosts file did not help, of course, as it's running dig if I recall correctly which by passes the /etc/hosts file? ERROR Reverse DNS resolution of address 192.168.0.154 (ipa02.xyz.abc.zyx) failed. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.) 2) Missing PTR records. Had to add a reverse zone and skip the overlap check as I'm working with a single subnet: IPA Error 3000: InvocationError DNS zone 0.168.192.in-addr.arpa. already exists in DNS and is handled by server(s): ad02.abc.zyx., ad01.abc.zyx. 3) Finally I reran ipa-replica-install which completed fine but indicated I only have CA configured for the master. So needed to uninstall all and redo this time running: !!!Important!!! you don't need to start over the replica install if you just want to add a CA instance on the replica. The command ipa-ca-install can be run on the replica and will configure a clone of the CA. ipa-replica-install --setup-ca --setup-dns --forwarder=192.168.0.VIP OCTET> 4) This time when running the above ipa-replica-install .. it complained that the keytab wasn't working despite uninstalling everything earlier using ipa-client-install --uninstall: ERROR Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/ipa02.xyz.abc@xyz.abc.zyx -H ldaps://ipa01.xyz.abc.zyx' returned non-zero exit status 9 So I removed a bunch of further entries from the master UI including the SRV records etc. The correct path would be [master]$ ipa-replica-manage del --force --clean to remove all remaining data related to the uninstalled replica. 5) Finally I got the following: Joining realm failed: Host is already joined. which I took care of by visiting the master then IPA Server -> Topology and removing any reference to ipa02. This adventure led me to believe that: 1) Perhaps there's some sort of guide online that I'm not finding, outlining all the prep work I needed to do? (Which you've now provided, thx.) The official documentation is Red Hat Enterprise Linux "Linux Domain Identity, Authentication, and Policy Guide" that can be found here [1]. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/ Thanks Florence! These are the bits I needed! 2) Perhaps I'm doing the right thing but these are potential issues? Thank you for the wiki. It does address use of the various options. Appeared as though ipa-replica-install without any options might pull this off the master, but it didn't. Cheers, TK HTH, flo [1] https://www.freeipa.org/page/Releases/4.3.0#New_method_-_domain_level_1 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahost
[Freeipa-users] Re: Replica creation using 'ipa-replica-prepare' to generate replica file,is supported only in 0-level IPA domain.
On 2/5/2019 5:12 AM, Florence Blanc-Renaud via FreeIPA-users wrote: On 2/5/19 8:15 AM, TomK via FreeIPA-users wrote: Hello, Would someone please point me to a concise list of steps I can use here? Running 1.) and 2.) yields various errors and I would like to try a known set of working commands to get a replica going in this state before posting with errors: # ipa-replica-prepare ipa04.abc.xyz.123 --ip-address 192.168.0.20 -p "PASS01" Replica creation using 'ipa-replica-prepare' to generate replica file is supported only in 0-level IPA domain. The current IPA domain level is 1 and thus the replica must be created by promoting an existing IPA client. To set up a replica use the following procedure: 1.) set up a client on the host using 'ipa-client-install' 2.) promote the client to replica running 'ipa-replica-install' *without* replica file specified 'ipa-replica-prepare' is allowed only in domain level 0 The ipa-replica-prepare command failed. Hi, the process to install a replica has evolved since IPA 4.3. If your master was installed with IPA 4.3+, then it is using domain level 1 by default (unless you specified ipa-server-install --domain-level 0 during the installation). In this case, please refer to this wiki [1] to install a replica. There is no need to create a replica file, and you can either: - install the future replica as a client with: $ ipa-client-install [options] then run ipa-replica-install to promote the machine from client to replica using: $ kinit admin $ ipa-replica-install or - directly install the replica using: $ ipa-replica-install --principal admin --admin-password xx [options] Thanks Florence! To add some background to the conversation, I ran into the following when trying just those commands: 1) Running ipa-replica-install reported errors if both the master and replica DNS entries did not appear in the master's zone / reverse files. Had to add them manually. The hosts file did not help, of course, as it's running dig if I recall correctly which by passes the /etc/hosts file? ERROR Reverse DNS resolution of address 192.168.0.154 (ipa02.xyz.abc.zyx) failed. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.) 2) Missing PTR records. Had to add a reverse zone and skip the overlap check as I'm working with a single subnet: IPA Error 3000: InvocationError DNS zone 0.168.192.in-addr.arpa. already exists in DNS and is handled by server(s): ad02.abc.zyx., ad01.abc.zyx. 3) Finally I reran ipa-replica-install which completed fine but indicated I only have CA configured for the master. So needed to uninstall all and redo this time running: ipa-replica-install --setup-ca --setup-dns --forwarder=192.168.0.OCTET> 4) This time when running the above ipa-replica-install .. it complained that the keytab wasn't working despite uninstalling everything earlier using ipa-client-install --uninstall: ERROR Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/ipa02.xyz.abc@xyz.abc.zyx -H ldaps://ipa01.xyz.abc.zyx' returned non-zero exit status 9 So I removed a bunch of further entries from the master UI including the SRV records etc. 5) Finally I got the following: Joining realm failed: Host is already joined. which I took care of by visiting the master then IPA Server -> Topology and removing any reference to ipa02. This adventure led me to believe that: 1) Perhaps there's some sort of guide online that I'm not finding, outlining all the prep work I needed to do? (Which you've now provided, thx.) 2) Perhaps I'm doing the right thing but these are potential issues? Thank you for the wiki. It does address use of the various options. Appeared as though ipa-replica-install without any options might pull this off the master, but it didn't. Cheers, TK HTH, flo [1] https://www.freeipa.org/page/Releases/4.3.0#New_method_-_domain_level_1 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
[Freeipa-users] Replica creation using 'ipa-replica-prepare' to generate replica file,is supported only in 0-level IPA domain.
Hello, Would someone please point me to a concise list of steps I can use here? Running 1.) and 2.) yields various errors and I would like to try a known set of working commands to get a replica going in this state before posting with errors: # ipa-replica-prepare ipa04.abc.xyz.123 --ip-address 192.168.0.20 -p "PASS01" Replica creation using 'ipa-replica-prepare' to generate replica file is supported only in 0-level IPA domain. The current IPA domain level is 1 and thus the replica must be created by promoting an existing IPA client. To set up a replica use the following procedure: 1.) set up a client on the host using 'ipa-client-install' 2.) promote the client to replica running 'ipa-replica-install' *without* replica file specified 'ipa-replica-prepare' is allowed only in domain level 0 The ipa-replica-prepare command failed. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: DHCP + FreeIPA: How to ensure DHCP only servers those IP's NOT defined in FreeIPA DNS?
On 2/3/2019 5:29 PM, Peter Fern via FreeIPA-users wrote: Either specify static allocations in your DHCP server, or set the IPs statically on the nodes from outside the dynamic range, or just enable DDNS updates in SSSD and it should update your DNS records to match whatever IP the node gets at boot. 1) Will try static allocations. 2) Set IP's statically: Not an option for me. Need them taken from a pool but more intelligently then DHCP has been doing. 3) DDNS updates would conflict with ipa-client registering the same machine I think. Correct me if I'm wrong here. 4) I've already scripted pulling the IP from DHCP using dhclient, checking IPA against reverse lookup then assigning it if it's free. So I'll adjust it in such a way that it will skip calling dhclient, and do the DNS checks and basic ping / nmap checks to see if it's free. Was hoping to get DHCP configured to check DNS to leverage the capabilities of both tools. Cheers, TK On 4/2/19 7:49 am, TomK via FreeIPA-users wrote: Hey All, Would like to ensure that if a DHCP server issues an IP, that it also checks the FreeIPA (DNS) to ensure that IP hasn't been defined before. Anyway to do that? Currently if a virtual host has been offline for a while, the DHCP serves it's IP to new hosts being built. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] DHCP + FreeIPA: How to ensure DHCP only servers those IP's NOT defined in FreeIPA DNS?
Hey All, Would like to ensure that if a DHCP server issues an IP, that it also checks the FreeIPA (DNS) to ensure that IP hasn't been defined before. Anyway to do that? Currently if a virtual host has been offline for a while, the DHCP serves it's IP to new hosts being built. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] IPA Infrastructure Design Question with multiple IPA Clusters
Suppose I have the following scenario: AD DC Cluster = b.a ( user: b.a\jack ) IPA Cluster 01 = c.b.a IPA Cluster 02 = d.b.a IPA Cluster 03 = e.b.a If I setup all 3 IPA clusters as subdomains of b.a, I know each one can establish a trust with the AD DC and I can authenticate as 'b.a\jack' through servers connected to each cluster. But if I want to do something like this (just theoretical): AD DC Cluster = b.a ( user: b.a\jack ) IPA Cluster 01 = c.b.a IPA Sub Cluster 01 = d.c.b.a IPA Sub Cluster 02 = e.c.b.a Meaning only c.b.a has a trust with the AD DC Cluster but d.c.b.a and e.c.b.a don't have a direct trust with the AD DC however c.b.a forwards anything on 'd' and 'e' over to the sub clusters. Can the IPA Cluster 01 'delegate' the AD DC trust to the sub IPA clusters? I imagine it's not possible. If by chance it is, what would I need to do to make that work? Guessing allowing the AD DC to trust the subdomains would be one of the things I need to do. But what else? -- Regards, TK - ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: ipa: ERROR: Nameserver 'd01.unix.dom.name.' does not have a corresponding A/AAAA record
Please disregard ( blame lack of sleep - :) ). On further reading I needed dns01.d01 A record set to IP 192.168.0.130 then a dns01 NS record set to dns01.d01 . https://www.freeipa.org/page/Troubleshooting/DNS#Forward_zone_does_not_work -- Cheers, Tom K. On 1/21/2019 9:33 AM, TomK via FreeIPA-users wrote: Hey All, I've 4 NS servers: ipa01.unix.dom.name 192.168.0.44 ipa02.unix.dom.name 192.168.0.45 and remote ones (Just simple named / DNS ) dns01.d01.unix.dom.name 192.168.0.130 dns02.d01.unix.dom.name 192.168.0.132 When using: 1) ipa dnsforwardzone-add d01.unix.dom.name --forwarder=192.168.0.130 --forwarder=192.168.0.132 --forward-policy=only 2) ipa dnsrecord-add unix.dom.name. d01 --ns-rec=d01.unix.dom.name. I'm greeted with: ipa: ERROR: Nameserver 'd01.unix.dom.name.' does not have a corresponding A/ record So I can add an A record on the IPA servers but perhaps this is looking for the A record on the forwarding DNS servers 192.168.0.130 and 192.168.0.132? If I'm adding it on the IPA side then I'll add d01 with two IP addresses to? Doesn't seem to make sense. I just need to forward on d01. I'm forwarding the whole subzone. What I have is: ipa-common-4.5.0-22.el7.centos.noarch python2-ipaclient-4.5.0-22.el7.centos.noarch python-ipaddress-1.0.16-2.el7.noarch ipa-client-common-4.5.0-22.el7.centos.noarch python-iniparse-0.4-9.el7.noarch ipa-server-common-4.5.0-22.el7.centos.noarch ipa-server-dns-4.5.0-22.el7.centos.noarch python-libipa_hbac-1.15.2-50.el7_4.8.x86_64 libipa_hbac-1.15.2-50.el7_4.8.x86_64 python2-ipaserver-4.5.0-22.el7.centos.noarch sssd-ipa-1.15.2-50.el7_4.8.x86_64 ipa-client-4.5.0-22.el7.centos.x86_64 ipa-python-compat-4.5.0-22.el7.centos.noarch ipa-server-trust-ad-4.5.0-22.el7.centos.x86_64 python2-ipalib-4.5.0-22.el7.centos.noarch ipa-server-4.5.0-22.el7.centos.x86_64 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] ipa: ERROR: Nameserver 'd01.unix.dom.name.' does not have a corresponding A/AAAA record
Hey All, I've 4 NS servers: ipa01.unix.dom.name 192.168.0.44 ipa02.unix.dom.name 192.168.0.45 and remote ones (Just simple named / DNS ) dns01.d01.unix.dom.name 192.168.0.130 dns02.d01.unix.dom.name 192.168.0.132 When using: 1) ipa dnsforwardzone-add d01.unix.dom.name --forwarder=192.168.0.130 --forwarder=192.168.0.132 --forward-policy=only 2) ipa dnsrecord-add unix.dom.name. d01 --ns-rec=d01.unix.dom.name. I'm greeted with: ipa: ERROR: Nameserver 'd01.unix.dom.name.' does not have a corresponding A/ record So I can add an A record on the IPA servers but perhaps this is looking for the A record on the forwarding DNS servers 192.168.0.130 and 192.168.0.132? If I'm adding it on the IPA side then I'll add d01 with two IP addresses to? Doesn't seem to make sense. I just need to forward on d01. I'm forwarding the whole subzone. What I have is: ipa-common-4.5.0-22.el7.centos.noarch python2-ipaclient-4.5.0-22.el7.centos.noarch python-ipaddress-1.0.16-2.el7.noarch ipa-client-common-4.5.0-22.el7.centos.noarch python-iniparse-0.4-9.el7.noarch ipa-server-common-4.5.0-22.el7.centos.noarch ipa-server-dns-4.5.0-22.el7.centos.noarch python-libipa_hbac-1.15.2-50.el7_4.8.x86_64 libipa_hbac-1.15.2-50.el7_4.8.x86_64 python2-ipaserver-4.5.0-22.el7.centos.noarch sssd-ipa-1.15.2-50.el7_4.8.x86_64 ipa-client-4.5.0-22.el7.centos.x86_64 ipa-python-compat-4.5.0-22.el7.centos.noarch ipa-server-trust-ad-4.5.0-22.el7.centos.x86_64 python2-ipalib-4.5.0-22.el7.centos.noarch ipa-server-4.5.0-22.el7.centos.x86_64 -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: IPA DNS Forwarders don't are not forwarding.
Hey John, Thanks! It was a DNS Forward Zone. However I had the policy set to 'Forward first'. I've recreated it using: ipa dnsforwardzone-add --skip-overlap-check my.dom --forwarder=192.168.0.224 --forward-policy=only And now things work the way they should be. Reading through some freeipa.org and redhat.com articles, seems to indicate that both should work since both forward to the defined forwarder 192.168.0.224. But that's not the case. This only works if the Forward Policy is set to 'only' when defining a DNS Forward Zone. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. On 10/2/2018 6:42 AM, John Petrini via FreeIPA-users wrote: Are you configuring forwarders within a regular zone or are you setting up a forwarding zone? I believe the latter will accomplish what you want. On Tue, Oct 2, 2018, 1:02 AM TomK via FreeIPA-users <mailto:freeipa-users@lists.fedorahosted.org>> wrote: Hey All, (Hopefully) a quick DNS Forwarding question. My Windows DNS is authoritative on MY.DOM . My IPA servers are authoritative on NIX.MY.DOM . Forwarding from the Windows DNS to the IPA DNS servers seems to work just fine. But not the other way despite having the forwarder defined in IPA: Zone name: my.dom. Active zone: TRUE Zone forwarders: 192.168.0.224, 192.168.0.220, 192.168.0.221 Forward policy: first So when I list the IPA DNS servers in /etc/resolv.conf first, they won't resolv on MY.DOM. But if I place the Windows DNS server first (192.168.0.224) then resolution on MY.DOM and NIX.MY.DOM work just fine. Any hints to make the forwarder work on the IPA side? -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org <mailto:freeipa-users-le...@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] IPA DNS Forwarders don't are not forwarding.
Hey All, (Hopefully) a quick DNS Forwarding question. My Windows DNS is authoritative on MY.DOM . My IPA servers are authoritative on NIX.MY.DOM . Forwarding from the Windows DNS to the IPA DNS servers seems to work just fine. But not the other way despite having the forwarder defined in IPA: Zone name: my.dom. Active zone: TRUE Zone forwarders: 192.168.0.224, 192.168.0.220, 192.168.0.221 Forward policy: first So when I list the IPA DNS servers in /etc/resolv.conf first, they won't resolv on MY.DOM. But if I place the Windows DNS server first (192.168.0.224) then resolution on MY.DOM and NIX.MY.DOM work just fine. Any hints to make the forwarder work on the IPA side? -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] ERR 20: Auth Rejected Credentials (client should begin new session)
Hey All, I have an external NFS cluster serviced by a VIP. The clients run autofs configured via IPA to provide NFS home directories to client. However, running into an issue on one of the clients and wondering if anyone seen this message from a tcpdump of a simple mount session that's preventing the mount: psql02: mount nfs-c01:/n /m Yields this message ERR 20: Auth Rejected Credentials (client should begin new session) and the mount attempt never exits and never mounts /m . nfs-c01 is a VIP that's serviced by HAproxy / keepalived. nfs-c01 however has a record in IPA Server, both forward and a reverse one. Using one of the underlying hosts that services nfs-c01 works and mounts succeeds for them. All VM hosts are clones of the same template. I have autofs running as part of this IPA client setup and applied the following fix as well: https://access.redhat.com/solutions/3261981 /m is a test mount folder I'm using on this client to troubleshoot the autofs mounting issue. So autofs is also running on the same hosts where I'm trying this mount from. Trying to trace the exact source of this error and not quite sure where to look further. idmipa01/02 are the IPA servers. (192.168.0.44/45 respectively) psql01/02 are the problem VM's. (192.168.0.108/124 ) nfs01/02 are the NFS hosts. (192.168.0.131/119 ) nfs-c01 192.168.0.80 This works fine on the other two VM hosts without any issue but I just can't find any difference comparing all the configs and so looking for suggestions to bounce off of. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. Apr 15 23:29:54 psql02 kernel: INFO: task mount.nfs:1443 blocked for more than 120 seconds. Apr 15 23:29:54 psql02 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 15 23:29:54 psql02 kernel: mount.nfs D 880135ed8000 0 1443 1442 0x0080 Apr 15 23:29:54 psql02 kernel: Call Trace: Apr 15 23:29:54 psql02 kernel: [] schedule_preempt_disabled+0x29/0x70 Apr 15 23:29:54 psql02 kernel: [] __mutex_lock_slowpath+0xc7/0x1d0 Apr 15 23:29:54 psql02 kernel: [] mutex_lock+0x1f/0x2f Apr 15 23:29:54 psql02 kernel: [] nfs4_discover_server_trunking+0x48/0x2e0 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] nfs4_init_client+0x126/0x300 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] ? kmem_cache_alloc+0x193/0x1e0 Apr 15 23:29:54 psql02 kernel: [] ? __fscache_acquire_cookie+0x66/0x180 [fscache] Apr 15 23:29:54 psql02 kernel: [] ? __fscache_acquire_cookie+0x66/0x180 [fscache] Apr 15 23:29:54 psql02 kernel: [] ? __rpc_init_priority_wait_queue+0x81/0xc0 [sunrpc] Apr 15 23:29:54 psql02 kernel: [] nfs_get_client+0x2c6/0x3e0 [nfs] Apr 15 23:29:54 psql02 kernel: [] nfs4_set_client+0x98/0x130 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] nfs4_create_server+0x13e/0x3b0 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] nfs4_remote_mount+0x2e/0x60 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] mount_fs+0x39/0x1b0 Apr 15 23:29:54 psql02 kernel: [] ? __alloc_percpu+0x15/0x20 Apr 15 23:29:54 psql02 kernel: [] vfs_kern_mount+0x67/0x110 Apr 15 23:29:54 psql02 kernel: [] nfs_do_root_mount+0x86/0xc0 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] nfs4_try_mount+0x44/0xc0 [nfsv4] Apr 15 23:29:54 psql02 kernel: [] ? get_nfs_version+0x27/0x90 [nfs] Apr 15 23:29:54 psql02 kernel: [] nfs_fs_mount+0x4c5/0xd90 [nfs] Apr 15 23:29:54 psql02 kernel: [] ? nfs_clone_super+0x140/0x140 [nfs] Apr 15 23:29:54 psql02 kernel: [] ? param_set_portnr+0x70/0x70 [nfs] Apr 15 23:29:54 psql02 kernel: [] mount_fs+0x39/0x1b0 Apr 15 23:29:54 psql02 kernel: [] ? __alloc_percpu+0x15/0x20 Apr 15 23:29:54 psql02 kernel: [] vfs_kern_mount+0x67/0x110 Apr 15 23:29:54 psql02 kernel: [] do_mount+0x233/0xaf0 Apr 15 23:29:54 psql02 kernel: [] SyS_mount+0x96/0xf0 Apr 15 23:29:54 psql02 kernel: [] system_call_fastpath+0x16/0x1b Apr 15 23:29:54 psql02 kernel: [] ? system_call_after_swapgs+0xca/0x214 Message from syslogd@psql01 at Apr 17 03:08:31 ... kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [mount.nfs:1606] Linux psql02.nix.my.dom 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@nfs02 log]# tcpdump -i eth0|grep -v "192.168.0.76"|grep -v NLB|grep -v nfs01|grep -v netbios|grep -v NBT tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 01:23:42.183158 IP nfs02.my.dom.xyz.60807 > idmipa01.my.dom.xyz.domain: 23358+ PTR? 76.0.168.192.in-addr.arpa. (43) 01:23:42.183884 IP idmipa01.my.dom.xyz.domain > nfs02.my.dom.xyz.60807: 23358 NXDomain* 0/1/0 (110) 01:23:42.184090 IP nfs02.my.dom.xyz.59911 > idmipa01.my.dom.xyz.domain: 29059+ PTR? 119.0.168.192.in-addr.arpa. (44) 01:23:42.184601 IP idmipa01.my.dom.xyz.domain >
[Freeipa-users] IPA Error 4203: DatabaseError: Constraint violation: Too soon to change password.
Hey Guy's, Not 'really' an issue but curious about the logic behind this scenario. I get a message saying "Your password expires in 4 days." So I go to change it for the admin user (I'm reusing the same pass) and type it in but then get this message: IPA Error 4203: DatabaseError Constraint violation: Too soon to change password. I do have a replica but no errors in the log (grep -Ei error /var/log/ipa/* yields no results on both nodes). So then why the message? Shouldn't it be perfectly legit to change the pass before it's expiration? Would like to be able to change it because in 4 days it won't be very convenient for me to do so. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: [SSSD-users] Re: Re: Re: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
600 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling umich_ldap->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: umich_ldap->name_to_gid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling umich_ldap->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: umich_ldap->name_to_gid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is 0 (Port 389 between client and server are open.) Seems like the line: Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: key: 0x62dd191 type: uid value: tomk@localdomain timeout 600 might be to blame. It's the first line that shows localdomain, but it should not. My hosts file: [root@ipaclient01 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.0.236 ipaclient01.nix.my.dom ipaclient01 [root@ipaclient01 ~]# Guessing key get's it's info from /etc/hosts directly and I should look at that? Cheers, Tom rob Cheers, Tom TomK via FreeIPA-users wrote: Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with owner and group as nobody / nobody when viewed from the client. Is there a way to structure /etc/idmapd.conf to allow for proper UID / GID resolution? Or perhaps another solution? [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" [General] Verbosity = 7 Domain = nix.my.dom [Mapping] [Translation] [Static] [UMICH_SCHEMA] LDAP_server = ldap-server.local.domain.edu LDAP_base = dc=local,dc=domain,dc=edu [root@client01 etc]# Mount looks like this: nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) /var/log/messages Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is 0 Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is 0 Mar 6 00:17:31 client01 systemd-logind: Removed session 23. Result of: systemctl restart rpcidmapd /var/log/messages --- Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on demand... Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand. Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service... Mar 5 23:48:5
[Freeipa-users] Re: [SSSD-users] Re: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
ething else on the IPA clients as well? In the existing IPA logs, no other log entries corrolate with the nfsidmapd messages on the client. Method = umich_ldap,nsswitch,static GSS-Methods = umich_ldap,nsswitch,static However it still lists: Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: user_dn : Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: passwd : Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: use_ssl : no Mar 15 01:15:56 ipaclient01 rpc.idmapd: rpc.idmapd: umichldap_init: ca_cert : and I'm not sure what variables idmapd.conf uses for password and user. Still, I've left the LAB KDC open so no users and passes are needed for simple lookups. After setting the above, the messages in the logs changed slightly: Mar 15 01:29:24 ipaclient01 systemd-logind: New session 5 of user tomk. Mar 15 01:29:24 ipaclient01 systemd: Started Session 5 of user tomk. Mar 15 01:29:24 ipaclient01 systemd: Starting Session 5 of user tomk. Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: key: 0x62dd191 type: uid value: tomk@localdomain timeout 600 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling umich_ldap->name_to_uid Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: umich_ldap->name_to_uid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 'tomk@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 'tomk@localdomain' does not map into domain 'nix.my.dom' Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: final return value is -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling umich_ldap->name_to_uid Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: umich_ldap->name_to_uid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nss_getpwnam: name 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: nfs4_name_to_uid: final return value is 0 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: key: 0x1917bd86 type: gid value: tomk@localdomain timeout 600 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling umich_ldap->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: umich_ldap->name_to_gid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling umich_ldap->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: umich_ldap->name_to_gid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is 0 (Port 389 between client and server are open.) Seems like the line: Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: key: 0x62dd191 type: uid value: tomk@localdomain timeout 600 might be to blame. It's the first line that shows localdomain, but it should not. My hosts file: [root@ipaclient01 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.0.236 ipaclient01.nix.my.dom ipaclient01 [root@ipaclient01 ~]# Guessing key get's it's info from /etc/hosts directly and I should look at that? Cheers, Tom rob Cheers, Tom TomK via FreeIPA-users wrote: Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with ow
[Freeipa-users] Re: [SSSD-users] Re: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
9:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is -22 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling umich_ldap->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: umich_ldap->name_to_gid returned -2 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 15 01:29:24 ipaclient01 nfsidmap[1855]: nfs4_name_to_gid: final return value is 0 (Port 389 between client and server are open.) Seems like the line: Mar 15 01:29:24 ipaclient01 nfsidmap[1853]: key: 0x62dd191 type: uid value: tomk@localdomain timeout 600 might be to blame. It's the first line that shows localdomain, but it should not. My hosts file: [root@ipaclient01 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.0.236 ipaclient01.nix.my.dom ipaclient01 [root@ipaclient01 ~]# Guessing key get's it's info from /etc/hosts directly and I should look at that? Cheers, Tom rob Cheers, Tom TomK via FreeIPA-users wrote: Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with owner and group as nobody / nobody when viewed from the client. Is there a way to structure /etc/idmapd.conf to allow for proper UID / GID resolution? Or perhaps another solution? [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" [General] Verbosity = 7 Domain = nix.my.dom [Mapping] [Translation] [Static] [UMICH_SCHEMA] LDAP_server = ldap-server.local.domain.edu LDAP_base = dc=local,dc=domain,dc=edu [root@client01 etc]# Mount looks like this: nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) /var/log/messages Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is 0 Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is 0 Mar 6 00:17:31 client01 systemd-logind: Removed session 23. Result of: systemctl restart rpcidmapd /var/log/messages --- Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on demand... Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand. Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS configuration... Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration. Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 cli
[Freeipa-users] Re: [SSSD-users] Re: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
On 3/7/2018 1:11 PM, Rob Crittenden wrote: Hey Rob, When starting idmapd or stopping it, logs on the LDAP server don't change. But UID and GID's change to nfsnobody when I set Nobody-User and Nobody-Group to nfsnobody in /etc/idmapd.conf . [General] Verbosity = 9 Domain = nix.my.dom [Mapping] Nobody-User = nfsnobody Nobody-Group = nfsnobody [Translation] [Static] [UMICH_SCHEMA] LDAP_server = idmipa01.nix.my.dom LDAP_base = cn=accounts,DC=NIX,DC=MY,DC=DOM LDAP_people_base = DC=NIX,DC=MY,DC=DOM LDAP_group_base = DC=NIX,DC=MY,DC=DOM Cheers, Tom TomK via FreeIPA-users wrote: Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with owner and group as nobody / nobody when viewed from the client. Is there a way to structure /etc/idmapd.conf to allow for proper UID / GID resolution? Or perhaps another solution? [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" [General] Verbosity = 7 Domain = nix.my.dom [Mapping] [Translation] [Static] [UMICH_SCHEMA] LDAP_server = ldap-server.local.domain.edu LDAP_base = dc=local,dc=domain,dc=edu [root@client01 etc]# Mount looks like this: nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) /var/log/messages Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is 0 Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is 0 Mar 6 00:17:31 client01 systemd-logind: Removed session 23. Result of: systemctl restart rpcidmapd /var/log/messages --- Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on demand... Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand. Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS configuration... Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration. Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14118]: Expiration time is 600 seconds. Mar 5 23:48:51 client01 systemd: Started NFSv4 ID-name mapping service. Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.nametoid/channel Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.idtoname/channel You might be able to correlate that to the 389-ds access log to see what queries are being executed. You probably need to set LDAP_people_base and LDAP_group_base as well. I think ipa-client-automount only sets the Domain value and doesn't configure the ldap section at all. rob __
[Freeipa-users] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'
Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with owner and group as nobody / nobody when viewed from the client. Is there a way to structure /etc/idmapd.conf to allow for proper UID / GID resolution? Or perhaps another solution? [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" [General] Verbosity = 7 Domain = nix.my.dom [Mapping] [Translation] [Static] [UMICH_SCHEMA] LDAP_server = ldap-server.local.domain.edu LDAP_base = dc=local,dc=domain,dc=edu [root@client01 etc]# Mount looks like this: nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) /var/log/messages Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'nob...@nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is 0 Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid value: t...@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is 0 Mar 6 00:17:31 client01 systemd-logind: Removed session 23. Result of: systemctl restart rpcidmapd /var/log/messages --- Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on demand... Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand. Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS configuration... Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration. Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14118]: Expiration time is 600 seconds. Mar 5 23:48:51 client01 systemd: Started NFSv4 ID-name mapping service. Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.nametoid/channel Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.idtoname/channel -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] ipa automountmap-add-indirect baltimore --parentmap=auto.share --mount=sub auto.man
Hey All, Noticed something and I'm wondering if I'm reading this right since the two commands below don't seem to behave in an equivalent manner. Should the first ipa automountmap-add-indirect below create the 'sub' key under map 'auto.share' or under map 'auto.man'? Create an indirect map with auto.share as a submount: ipa automountmap-add-indirect baltimore --parentmap=auto.share --mount=sub auto.man This is equivalent to: ipa automountmap-add-indirect baltimore --mount=/man auto.man ipa automountkey-add baltimore auto.man --key=sub --info="-fstype=autofs ldap:auto.share" -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: [SSSD-users] Re: Re: Auto create NFS home folders on IPA Server.
On 2/28/2018 11:19 PM, TomK wrote: On 2/27/2018 3:40 AM, Alexander Bokovoy wrote: On ti, 27 helmi 2018, TomK via FreeIPA-users wrote: On 2/26/2018 1:27 AM, Alexander Bokovoy via FreeIPA-users wrote: Thanks Alex. + SSSD mailing list. Two remaining questions. 1) Creating the NFS user folders on the server itself is not a problem however I would like to trap events that indicate USER logged into a client host. On this event, a home directory could then be created on the FreeIPA side. Without such an event I can't precreate it. So when a user logs into a client machine, is there any SSSD call initiated to the FreeIPA server that would show up in a log for example that I could in turn use to run a small shell script to precreate the user's home folder, if it doesn't exist? This is not something FreeIPA can help with. We already have pam_oddjob_mkhomedir module and its default configuration provides you a way to create directories out of band using oddjob-mkhomedir helper. I think at the very least you can have a wrapper that: - would check some configuration and push a message to some server to create a home directory somewhere else - would wait for a response back that a directory is created (either by polling a home directory appearance or communicating some other way with the remote tool that creates a directory) - would otherwise call a standard helper provided by oddjob-mkhomedir See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. Ty. Yes, thinking along those lines. Netcat w/ bash maybe (https://tinyurl.com/yat9k3hv), but simpler. Not sure yet. I'm able to write a small python job that will send the username logging in to the remote server for directory creation. Not great but a start. Not sure if this is the right place to ask but curious how get the user logging in and pass it to this script from within the oddjobd daemon? Anyway, I can't pass the user logging in into the code. # cat oddjobd-mkhomedir.conf . . . . . . Btw, above mkhomedir doesn't work on NFS v4 mounted folders anyway. 2) Is there a way to get SSSD to retrieve the unixHomeDirectory that's defined in the UNIX Attribute on the AD side? Would be handy if I want to control all home directory locations on the AD side. The override_homedir works to force a folder but when I try the %o option to override_homedir, it appears to take the FreeIPA default home directory, not the AD one. unixHomeDirectory is the default for ldap_user_home_directory for AD provider. Since all IPA trusted subdomains are using AD provider, unixHomeDirectory would just be used automatically. Only override_homedir works for me. User 'tom' in AD has unixHomeDirectory set to /home/tom but on a unix client connected to FreeIPA home directory is always /home/my.dom/tom instead of just /home/tom . Scratching my head as to what I might be missing here or not understanding well enough. My config: [domain/nix.my.dom] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = nix.my.dom id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaclient01.nix.my.dom chpass_provider = ipa ipa_server = idmipa01.nix.my.dom, idmipa02.nix.my.dom ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = UserHomeDir01 # Added after below home dir variables didn't work. No effect. dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true # override_homedir = /n/%d/%u # This did not work. fallback_homedir = /n/%d/%u ldap_user_home_directory = unixHomeDirectory [sssd] debug_level = 9 services = nss, sudo, pam, autofs, ssh config_file_version = 2 domains = nix.my.dom [nss] debug_level = 9 homedir_substring = /n [pam] debug_level = 9 [sudo] debug_level = 9 [autofs] . . . Cheers, Tom On su, 25 helmi 2018, TomK via FreeIPA-users wrote: Hey Guy's, For newly added AD or IPA users, is there a way to automatically create the user folders on the FreeIPA server under say /nfs/home/bill, for example so that when the remote client logs in, it sees the NFS mounted folder? Instructions that I can find right now require precreating the folders. Need them precreated via the FreeIPA master servers anytime someone attempts to login on a client using their AD credentials. Is this possible? Assume the NFS server will be local to the FreeIPA masters. One needs to create home directories on the NFS server itself. If home directories are mounted via NFS, then you need to have enough permission to create the folder at the NFS root which is not what you'd want to allow a regular user. Thus, it needs to be solved outside of a log-in flow. We don't provide any means to solve this in FreeIPA because file sharing/hosting is not a FreeIPA problem. If your NFS server is running on an IPA master, though, you might want to consider
[Freeipa-users] Re: [SSSD-users] Re: Re: Auto create NFS home folders on IPA Server.
On 2/27/2018 3:40 AM, Alexander Bokovoy wrote: On ti, 27 helmi 2018, TomK via FreeIPA-users wrote: On 2/26/2018 1:27 AM, Alexander Bokovoy via FreeIPA-users wrote: Thanks Alex. + SSSD mailing list. Two remaining questions. 1) Creating the NFS user folders on the server itself is not a problem however I would like to trap events that indicate USER logged into a client host. On this event, a home directory could then be created on the FreeIPA side. Without such an event I can't precreate it. So when a user logs into a client machine, is there any SSSD call initiated to the FreeIPA server that would show up in a log for example that I could in turn use to run a small shell script to precreate the user's home folder, if it doesn't exist? This is not something FreeIPA can help with. We already have pam_oddjob_mkhomedir module and its default configuration provides you a way to create directories out of band using oddjob-mkhomedir helper. I think at the very least you can have a wrapper that: - would check some configuration and push a message to some server to create a home directory somewhere else - would wait for a response back that a directory is created (either by polling a home directory appearance or communicating some other way with the remote tool that creates a directory) - would otherwise call a standard helper provided by oddjob-mkhomedir See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. Ty. Yes, thinking along those lines. Netcat w/ bash maybe (https://tinyurl.com/yat9k3hv), but simpler. Not sure yet. 2) Is there a way to get SSSD to retrieve the unixHomeDirectory that's defined in the UNIX Attribute on the AD side? Would be handy if I want to control all home directory locations on the AD side. The override_homedir works to force a folder but when I try the %o option to override_homedir, it appears to take the FreeIPA default home directory, not the AD one. unixHomeDirectory is the default for ldap_user_home_directory for AD provider. Since all IPA trusted subdomains are using AD provider, unixHomeDirectory would just be used automatically. Only override_homedir works for me. User 'tom' in AD has unixHomeDirectory set to /home/tom but on a unix client connected to FreeIPA home directory is always /home/my.dom/tom instead of just /home/tom . Scratching my head as to what I might be missing here or not understanding well enough. My config: [domain/nix.my.dom] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = nix.my.dom id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaclient01.nix.my.dom chpass_provider = ipa ipa_server = idmipa01.nix.my.dom, idmipa02.nix.my.dom ldap_tls_cacert = /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = UserHomeDir01 # Added after below home dir variables didn't work. No effect. dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true # override_homedir = /n/%d/%u # This did not work. fallback_homedir = /n/%d/%u ldap_user_home_directory = unixHomeDirectory [sssd] debug_level = 9 services = nss, sudo, pam, autofs, ssh config_file_version = 2 domains = nix.my.dom [nss] debug_level = 9 homedir_substring = /n [pam] debug_level = 9 [sudo] debug_level = 9 [autofs] . . . Cheers, Tom On su, 25 helmi 2018, TomK via FreeIPA-users wrote: Hey Guy's, For newly added AD or IPA users, is there a way to automatically create the user folders on the FreeIPA server under say /nfs/home/bill, for example so that when the remote client logs in, it sees the NFS mounted folder? Instructions that I can find right now require precreating the folders. Need them precreated via the FreeIPA master servers anytime someone attempts to login on a client using their AD credentials. Is this possible? Assume the NFS server will be local to the FreeIPA masters. One needs to create home directories on the NFS server itself. If home directories are mounted via NFS, then you need to have enough permission to create the folder at the NFS root which is not what you'd want to allow a regular user. Thus, it needs to be solved outside of a log-in flow. We don't provide any means to solve this in FreeIPA because file sharing/hosting is not a FreeIPA problem. If your NFS server is running on an IPA master, though, you might want to consider not using NFS mounts on that server itself. In this case a normal oddjob-based pam_mkhomedir would create the directories just fine. Found steps like the one below but step 5) still requires pre creation of the folders. https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun
[Freeipa-users] Re: Auto create NFS home folders on IPA Server.
On 2/26/2018 1:27 AM, Alexander Bokovoy via FreeIPA-users wrote: Thanks Alex. + SSSD mailing list. Two remaining questions. 1) Creating the NFS user folders on the server itself is not a problem however I would like to trap events that indicate USER logged into a client host. On this event, a home directory could then be created on the FreeIPA side. Without such an event I can't precreate it. So when a user logs into a client machine, is there any SSSD call initiated to the FreeIPA server that would show up in a log for example that I could in turn use to run a small shell script to precreate the user's home folder, if it doesn't exist? 2) Is there a way to get SSSD to retrieve the unixHomeDirectory that's defined in the UNIX Attribute on the AD side? Would be handy if I want to control all home directory locations on the AD side. The override_homedir works to force a folder but when I try the %o option to override_homedir, it appears to take the FreeIPA default home directory, not the AD one. Cheers, Tom On su, 25 helmi 2018, TomK via FreeIPA-users wrote: Hey Guy's, For newly added AD or IPA users, is there a way to automatically create the user folders on the FreeIPA server under say /nfs/home/bill, for example so that when the remote client logs in, it sees the NFS mounted folder? Instructions that I can find right now require precreating the folders. Need them precreated via the FreeIPA master servers anytime someone attempts to login on a client using their AD credentials. Is this possible? Assume the NFS server will be local to the FreeIPA masters. One needs to create home directories on the NFS server itself. If home directories are mounted via NFS, then you need to have enough permission to create the folder at the NFS root which is not what you'd want to allow a regular user. Thus, it needs to be solved outside of a log-in flow. We don't provide any means to solve this in FreeIPA because file sharing/hosting is not a FreeIPA problem. If your NFS server is running on an IPA master, though, you might want to consider not using NFS mounts on that server itself. In this case a normal oddjob-based pam_mkhomedir would create the directories just fine. Found steps like the one below but step 5) still requires pre creation of the folders. https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Auto create NFS home folders on IPA Server.
Hey Guy's, For newly added AD or IPA users, is there a way to automatically create the user folders on the FreeIPA server under say /nfs/home/bill, for example so that when the remote client logs in, it sees the NFS mounted folder? Instructions that I can find right now require precreating the folders. Need them precreated via the FreeIPA master servers anytime someone attempts to login on a client using their AD credentials. Is this possible? Assume the NFS server will be local to the FreeIPA masters. Found steps like the one below but step 5) still requires pre creation of the folders. https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 2/1/2018 3:30 AM, Jakub Hrozek via FreeIPA-users wrote: On Wed, Jan 31, 2018 at 04:07:46PM -0500, TomK via FreeIPA-users wrote: On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote: On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote: On 1/31/2018 12:21 PM, TomK wrote: On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. Also confirmed that port 3268 from both clients to the AD DC is blocked in F/W. However then that raises the question why authentication works on http-srv01 even though traffic to port 3268 is also getting denied from that host. The 'port' here refers to an internal sssd structure that usually maps to a network port, but not always. Is there some more context around the very first 'not working' since the sssd restart? Because here is not much, there's just connecting and then not working which leaves me puzzled. The very first state switch should have a message from "_be_fo_set_port_status" which also includes who was the caller etc. That should give some more context. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Below is the snippet. (Wed Jan 31 13:28:09 2
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 4:07 PM, TomK via FreeIPA-users wrote: On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote: On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote: On 1/31/2018 12:21 PM, TomK wrote: On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. Also confirmed that port 3268 from both clients to the AD DC is blocked in F/W. However then that raises the question why authentication works on http-srv01 even though traffic to port 3268 is also getting denied from that host. The 'port' here refers to an internal sssd structure that usually maps to a network port, but not always. Is there some more context around the very first 'not working' since the sssd restart? Because here is not much, there's just connecting and then not working which leaves me puzzled. The very first state switch should have a message from "_be_fo_set_port_status" which also includes who was the caller etc. That should give some more context. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Below is the snippet. (Wed Jan 31 13:28:09 2018) [sssd[be[ADDOM]]] [ldb] (0x4000): Destroying t
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote: On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote: On 1/31/2018 12:21 PM, TomK wrote: On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. Also confirmed that port 3268 from both clients to the AD DC is blocked in F/W. However then that raises the question why authentication works on http-srv01 even though traffic to port 3268 is also getting denied from that host. The 'port' here refers to an internal sssd structure that usually maps to a network port, but not always. Is there some more context around the very first 'not working' since the sssd restart? Because here is not much, there's just connecting and then not working which leaves me puzzled. The very first state switch should have a message from "_be_fo_set_port_status" which also includes who was the caller etc. That should give some more context. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Below is the snippet. (Wed Jan 31 13:28:09 2018) [sssd[be[ADDOM]]] [ldb] (0x4000): Destroying timer event 0x55d9c6aa2020 "ltdb_timeout" (Wed Jan 31 13:28:09 2018) [s
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote: On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote: On 1/31/2018 12:21 PM, TomK wrote: On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. Also confirmed that port 3268 from both clients to the AD DC is blocked in F/W. However then that raises the question why authentication works on http-srv01 even though traffic to port 3268 is also getting denied from that host. The 'port' here refers to an internal sssd structure that usually maps to a network port, but not always. Is there some more context around the very first 'not working' since the sssd restart? Because here is not much, there's just connecting and then not working which leaves me puzzled. The very first state switch should have a message from "_be_fo_set_port_status" which also includes who was the caller etc. That should give some more context. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org TY. I've sent the snippet privately to you. -- Cheers, Tom K. - Living on earth is
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 12:21 PM, TomK wrote: On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. Also confirmed that port 3268 from both clients to the AD DC is blocked in F/W. However then that raises the question why authentication works on http-srv01 even though traffic to port 3268 is also getting denied from that host. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but ignore mark offline is enabled. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP Request [Account
[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 9:41 AM, Jakub Hrozek wrote: See inline.. On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote: On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' What debug level are you running with? Is this the first occurence of 'port not working' since sssd started? It's debug_level = 9. There was 1002 occurrances since I restarted sssd last night. If it's F/W, I'm not clear on the port this is referring too. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but ignore mark offline is enabled. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP Request [Account #4]: Receiving request data. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #4]: Finished. Success. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5
[Freeipa-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote: My bad, did not include sssd-users earlier. :( Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but ignore mark offline is enabled. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP Request [Account #4]: Receiving request data. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #4]: Finished. Success. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2::ADDOM:name=unix-admin-group@addom] from reply ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users
[Freeipa-users] Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed
Hey All, I'm wondering if anyone came across this error below. We have two RHEL 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02 Both connect to the same AD DC host below: addc-srv03.addom.com. Verified krb5.conf and sssd.conf both are identical. We can login on the http-srv01 and can list all groups for an AD account. On http-srv02 we cannot login and any group listing from the CLI result only in the user's local groups. No AD groups. Logs give us the output below. Short of adding in the entire log which I might not be able to do till the end of the week, what could we look at to resolve this? There's very little available online on this error. The RH solution doesn't make sense since the first host connects and authenticates users just fine so it's definitely GC enabled. -- Cheers, Tom K. - Living on earth is expensive, but it includes a free trip around the sun. samba-libs-4.6.2-12.el7_4.x86_64 samba-client-libs-4.6.2-12.el7_4.x86_64 sssd-1.15.2-50.el7_4.6.x86_64 openldap-2.4.44-5.el7.x86_64 sssd-ldap-1.15.2-50.el7_4.6.x86_64 sssd-common-pac-1.15.2-50.el7_4.6.x86_64 samba-winbind-clients-4.6.2-12.el7_4.x86_64 samba-common-4.6.2-12.el7_4.noarch sssd-client-1.15.2-50.el7_4.6.x86_64 sssd-proxy-1.15.2-50.el7_4.6.x86_64 samba-winbind-modules-4.6.2-12.el7_4.x86_64 python-sssdconfig-1.15.2-50.el7_4.6.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 samba-common-libs-4.6.2-12.el7_4.x86_64 sssd-krb5-common-1.15.2-50.el7_4.6.x86_64 samba-winbind-4.6.2-12.el7_4.x86_64 sssd-krb5-1.15.2-50.el7_4.6.x86_64 sssd-ad-1.15.2-50.el7_4.6.x86_64 sssd-common-1.15.2-50.el7_4.6.x86_64 samba-common-tools-4.6.2-12.el7_4.x86_64 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus conn: 0x55b2e22e8700 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP Request [Account #4]: New request. Flags [0x0001]. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] (0x1000): Domain ADDOM is Active (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000): Status of server 'addc-srv03.addom.com' is 'working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): Port status of port 0 for server 'addc-srv03.addom.com' is 'not working' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] (0x0020): No available servers for service 'AD_GC' (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] (0x1000): Server resolution failed: [5]: Input/output error (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but ignore mark offline is enabled. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error] (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP Request [Account #4]: Receiving request data. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #4]: Finished. Success. (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2::ADDOM:name=unix-admin-group@addom] from reply ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
