[Freeipa-users] FreeIPA client installation on ubuntu 14.04
Hi All, I am trying to install freeipa client on my ubuntu client via ansible script. I have "apt-get update" and "apt-get install freeipa-client -y" these basic commands added in my playbook but the problem is when i run "apt-get install freeipa-client" with or without -y option it opens up some graphical interface confirming the IPA realm and other details. I did not find any option with in "apt-get install freeipa-client"to make it deployment unattended. Can anyone please tell me the how i can automate ipa-client installation on ubuntu? The same process works fine with RHEL using yum but i am unable to do so for ubuntu with apt-get Thanks,Deepak -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Me Again
I used to have a lot of replicas, but like a house of cards, it all came crashing down. I was down to two, that seemed to be replicating, but last few days I've noticed that they haven't always been. freeipa-sea.bpt.rocks is where we do all our admin. seattlenfs.bpt.rocks is also up and running and can be used for authentication. When I noticed that logins were failing after password changes I did ipa-replica-manage re-initialize --from=freeipa-sea.bpt.rocks on seattlenfs.bpt.rocks and replication appeared to be working again. Well it happened again, and this time I peeked at the dirsrv errors log and saw some scary things having to do with the CA. [19/Sep/2016:02:55:50 -0700] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 0 (Success) [19/Sep/2016:02:55:50 -0700] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [19/Sep/2016:02:55:50 -0700] NSMMReplicationPlugin - agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [19/Sep/2016:02:56:04 -0700] NSMMReplicationPlugin - agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind with GSSAPI auth resumed [20/Sep/2016:10:18:25 -0700] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=bpt,dc=rocks is going offline; disabling replication [20/Sep/2016:10:18:26 -0700] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [20/Sep/2016:10:18:29 -0700] - import userRoot: Workers finished; cleaning up... [20/Sep/2016:10:18:29 -0700] - import userRoot: Workers cleaned up. [20/Sep/2016:10:18:29 -0700] - import userRoot: Indexing complete. Post-processing... [20/Sep/2016:10:18:29 -0700] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [20/Sep/2016:10:18:29 -0700] - import userRoot: Generating numSubordinates complete. [20/Sep/2016:10:18:29 -0700] - import userRoot: Gathering ancestorid non-leaf IDs... [20/Sep/2016:10:18:29 -0700] - import userRoot: Finished gathering ancestorid non-leaf IDs. [20/Sep/2016:10:18:29 -0700] - import userRoot: Creating ancestorid index (new idl)... [20/Sep/2016:10:18:29 -0700] - import userRoot: Created ancestorid index (new idl). [20/Sep/2016:10:18:29 -0700] - import userRoot: Flushing caches... [20/Sep/2016:10:18:29 -0700] - import userRoot: Closing files... [20/Sep/2016:10:18:29 -0700] - import userRoot: Import complete. Processed 1324 entries in 3 seconds. (441.33 entries/sec) [20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=bpt,dc=rocks is coming online; enabling replication [20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica dc=bpt,dc=rocks does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target ou=sudoers,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=users,cn=compat,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NS
Re: [Freeipa-users] login auth fails then success
On Tue, Sep 20, 2016 at 02:03:38PM +, Larry Rosen wrote: > Thanks, that explains a lot (I didn't catch the difference in auth services). > Would this be mitigated by putting sss in front of files in nsswitch.conf)? > > /etc/nsswitchconf: > passwd: files sss > shadow: files sss > group: files sss No, NSS is a separate interface. You can experiment with adding pam_localuser.so before pam_unix, though. btw this is how recent Fedora releases configure their PAM stack: authrequired pam_env.so authsufficientpam_fprintd.so auth[default=1 success=ok] pam_localuser.so auth[success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 1000 quiet_success authsufficientpam_sss.so forward_pass authrequired pam_deny.so But watch out, PAM stacks are inherently distro-specific and I don't remember what exactly you're running. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] login auth fails then success
Thanks, that explains a lot (I didn't catch the difference in auth services). Would this be mitigated by putting sss in front of files in nsswitch.conf)? /etc/nsswitchconf: passwd: files sss shadow: files sss group: files sss Date: Sun, 18 Sep 2016 22:14:59 +0200 From: Jakub Hrozek To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] login auth fails then success Message-ID: <20160918201459.uhijnc4gyfykgzic@hendrix> Content-Type: text/plain; charset=us-ascii On Fri, Sep 16, 2016 at 06:23:03PM +, Larry Rosen wrote: > Sorry I thought I had pasted these previously: > > What other logs do I need to add (maybe from the IPA server)? > > Client system's /var/log/secure: > > Sep 13 19:12:33 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:12:33 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:18:11 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:18:11 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:22:52 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:22:53 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:23:49 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:23:49 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:28:24 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:28:24 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:29:27 il10-app-xfs udcs: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web Sep 13 19:29:27 il10-app-xfs udcs: pam_sss(login:auth): > authentication success; logname= uid=0 euid=0 tty= ruser= rhost= > user=il10web I think these are expected. Authentication using pam_unix fails because pam_unix doesn't know this particular users and then pam_sss succeeds. I wonder if the best way to deal with the log messages is just to configure logrotate a bit more aggressively? > > -Original Message- > From: Rob Crittenden [mailto:rcrit...@redhat.com] > Sent: Friday, September 16, 2016 1:39 PM > To: Larry Rosen ; > freeipa-users@redhat.com > Subject: Re: [Freeipa-users] login auth fails then success > > Larry Rosen wrote: > > We have a web app that logs in using a service (automated login > > user, non-expiring, non-failure count) account that leaves these log > > entries all day long. This does not appear to cause any problems, > > it just make my logs grow unnecessarily and creates a lot of "noise" in the > > log. > > > > Any ideas why it initially fails and then works?** > > Logs where? Can we see them? > > rob > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE
ok, so all certs are renewed (dogldap and http). On Tue, Sep 20, 2016 at 11:49 AM, Natxo Asenjo wrote: > > > On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden > wrote: > >> Natxo Asenjo wrote: >> >>> hi, >>> >>> >>> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden >> >> Ok, how about we work around the problem. >> > > Gladly ;-) > > >> Since it is failing on the revocation what you might try is removing the >> userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry. >> >> I think this will work: >> >> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial >> >> >> $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl >> >> If this doesn't work you can use ldapmodify to delete the usercertificate >> value. >> >> This will remove the certificate value so there is nothing to revoke and >> a new cert will be saved (hopefully). >> >> Now try to resubmit the request via certmonger. >> >> It if works then you can run ipa cert-revooke >> >> It isn't a great answer long-term because it is really just working >> around the problem but it should get the certs renewed. >> >> > ok, so I restarted the httpd service then I could use ipa service-show: > > $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial > Serial Number: 175 > Serial Number (hex): 0xAF > bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl > --- > Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl" > --- > Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl > Managed by: kdc01.unix.iriszorg.nl > > > bash-4.1$ sudo ipa-getcert resubmit -i 20121107212513 > Resubmitting "20121107212513" to "IPA". > bash-4.1$ sudo getcert list > Number of certificates and requests being tracked: 8. > Request ID '20121107212513': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. Certificate operation cannot be completed: Failure decoding > Certificate Signing Request). > stuck: yes > key pair storage: type=NSSDB,location='/etc/ > dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt' > certificate: type=NSSDB,location='/etc/ > dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL > subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL > expires: 2016-10-12 10:49:24 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib/ipa/certmonger/restart_dirsrv > UNIX-IRISZORG-NL > track: yes > auto-renew: yes > > > > the certificate is gone: > $ ipa service-show ldap/kdc01.unix.iriszorg.nl > ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log' > Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl > Keytab: True > Managed by: kdc01.unix.iriszorg.nl > > > But then I thought, what the hell, let's try again, restarted httpd, > resubmitted it, and now it did work ;-) > > $ ipa service-show ldap/kdc01.unix.iriszorg.nl > Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl > Certificate: MIIDrDCCApSgAwIBAgICAPUwDQYJKo > ZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1 > UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDT > E4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB > 0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQ > EBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1 > snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+ > iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+ > Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/ > k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icx > R6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaO > BuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggr > BgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4Lmly > aXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQ > UFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/ > BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZ > xEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO+ > Dwg1TzItQqXxgHtCqcQ7bmahj2AMPRNUXeZck0p/eueG4wj2kbLwTLU6cOfwnT4IOfszAS > 9GCql6oQIXlOfG6i6DAodBpgWziDfIrRJsJi4ZE+FvJL/ImJDdW+ > En50UyGp0n31oMSDIxWf1bdWUctSEYhcy9JftzkitNm1FD+a1HzeYyuHthzlHHcSIXN/ > kXRSGktpe8VHE5XLtKnH92vmkMnyxZvE///2+ExHXIAOkwq3ck= > Keytab: True > Managed by: kdc01.unix.iriszorg.nl > Subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL > Serial Number: 245 > Serial Number (hex): 0xF5 > Issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL > Not Before: Tue Sep 20 08:06:58 2016 UTC > Not After: Fri Sep 21 08:06:58 2018 UTC >
Re: [Freeipa-users] 3rd party Cert install now IPA total broken
Hello. Thanks for the first help, Am Montag, 19. September 2016, 12:02:19 schrieb Florence Blanc-Renaud: > On 09/16/2016 03:06 PM, Günther J. Niederwimmer wrote: > > Hello, > > Freeipa 4.3.1 > > > > I have now install a 3rd Party Certificat from Startcom now my IPA is > > total > > broken? > > ipa-cacert-manage -p '' -n STARTCOM-ROOT -t C,, install > > root.crt I mean this is the wrong cert I installed :-(. Is it possible to overwrite or delete and make it new. this file is the ROOT-CA from STARTCOM ("30 Years") > > ipa-certupdate > > > > ipa-server-certinstall -w -d ipa_3rd_ca.p12 This was wrong, I delete all this installed certs with Certutil -d . -D -n xxx > > I create this p12 with key.pem, cert.pem root.crt now i create a new p12 with I hope the correct certs I become from Startcom a httpd zip file with 1_root_bundle.crt ("15 Years")and my wild-card Certificate this I included in my new created p12 with my key.pem. This p12 I Installed on the first master with pk12util -v -i ipa_4gjn_ca.p12 -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt -W pk12util -v -i ipa_4gjn_ca.p12 -d /etc/dirsrv/slapd-4GJN-COM -k /etc/dirsrv/slapd-4GJN-COM/pwdfile.txt -W xxx and pk12util -v -i ipa_4gjn_ca.p12 -d /var/lib/pki/pki-tomcat/alias -k /etc/pki/pki-tomcat/pwdfile.txt -W x I change the nss.conf and I hope the correct file in /etc/dirsrv/slapd- /dsl.ldif Then I change in all NSS DB the StartCOM Cert (1_root_bundle.crt) with name STARTCOM-ROOT to certutil -d . -M -t C,, -n STARCOM-ROOT afterward I make a reboot and a test ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa-ods-exporter Service: STOPPED ods-enforcerd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful Why is ipa-ods-exporter Service always STOPPED ?? The next I Test a login on the Web UI from IPA, this is now also working ;-) the QUESTION is now what is with the second master and the IPA- clients Now (?) I have also found the ipa-backup ;-) OK, for the next Problem now I know it :-). Have I to repeat this all on the second Master ? and what is the correct way to inform the clients ? Thanks again for a answer, > Hi, > > there were some issues with ipa-server-certinstall (see tickets #4785, > #4786 and #6263). > In order to check your configuration, you must make sure that the NSS > DBs for Apache and the LDAP server (/etc/httpd/alias, > /var/lib/pki/pki-tomcat/alias, /etc/dirsrv/slapd-DOMxx) contain: > - the server certificate with flags u,u,u (= the one contained in > ipa_3rd_ca.p12) > - the certificate of the CA which signed the server certificate, with > flags C,, (= the one contained in root.rt) > > Then you can also check if the nickname for the server cert is properly > set in /etc/httpd/conf.d/nss.conf (in the directive NSSNickname), and in > the LDAP entry cn=RSA,cn=encryption,cn=config (in the attribute > nsSSLPersonalitySSL). > > If this doesn't fix the issue, the logs of pki-tomcat/ca/debug may > provide more information. > > Also note that it is important to run ipa-certupdate on all the clients > and replicas in order to install the new certificates in the NSS DBs > *before* you run ipa-server-certinstall. > > Hope this helps, > Flo. > > > the kerberos don't start anymore ? > > The Error Is > > > > Unspecified GSS failure.Minor (2529639068): Cannot contact any KDC for > > realm> > > '4GJN.COM' > > > > after insert in nss.conf > > "NSSEnforceValidCerts off" > > > > ipactl restart is starting (?) but > > > > ipactl status tell me > > Directory Service: RUNNING > > krb5kdc Service: RUNNING > > kadmin Service: RUNNING > > named Service: RUNNING > > ipa_memcached Service: RUNNING > > httpd Service: RUNNING > > ipa-custodia Service: RUNNING > > pki-tomcatd Service: RUNNING > > ipa-otpd Service: RUNNING > > ipa-ods-exporter Service: STOPPED > > ods-enforcerd Service: RUNNING > > ipa-dnskeysyncd Service: RUNNING > > ipa: INFO: The ipactl command was successful > > > > with certutil -d /etc/httpd/alias -L I have now this > > Certificate Nickname Trust > > Attributes> > > SSL,S/MIME,JA > > R/XPI > > > > Signing-Cert u,u,u > > 4GJN_CA_FILE u,u,u > > ipaCert u,u,u > > 4GJN.COM IPA CA CT,C,C > > STARTCOM-ROOTC,, > > > > I can Insert in nss.conf by the > > #NSSNickname "Signing-Cert" original > > or > > NSSNicknam
[Freeipa-users] IPA Server is not coming backup
Hi All, My IPA Server was working all fine until i tried restarting it using "ipactl restart" and now i am ended with these errors :( [root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named ServiceJob for named-pkcs11.service failed because the control process exited with error code. See "systemctl status named-pkcs11.service" and "journalctl -xe" for details.Failed to start named ServiceShutting down Aborting ipactl This is what i get with "systemctl status named-pkcs11.service" [root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11 Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2016-09-20 06:28:03 EDT; 1min 2s ago Process: 3281 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, status=1/FAILURE) Process: 3278 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/US-WEST-2.C...database)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may...er failedSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't establish connection in LDAP connection pool: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic database 'ipa' configuration failed: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading configuration: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due to fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service: control process exited, code=exited status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service failed. Hint: Some lines were ellipsized, use -l to show in full. output from "journalctl -xe" is as below: [root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: couldn't establish connection in LDAP connection pool: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: dynamic database 'ipa' configuration failed: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: loading configuration: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due to fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service: control process exited, code=exited status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.-- Subject: Unit named-pkcs11.service has failed-- Defined-By: systemd-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel-- -- Unit named-pkcs11.service has failed.-- -- The result is failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal polkitd[529]: Unregistered Authentication Agent for unix-process:3498:364279453 (system bus name :1.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal polkitd[529]: Registered Authentication Agent for
Re: [Freeipa-users] IPA Server is not coming backup
Hi, The important line is around > named-pkcs11[3511]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information Unfortunately the log is truncated so it does not show the actual error. Please see https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart I hope it helps. Petr^2 Spacek On 20.9.2016 12:45, Deepak Dimri wrote: > Hi All, > My IPA Server was working all fine until i tried restarting it using "ipactl > restart" and now i am ended with these errors :( > > > > > > > > > [root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory > ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named > ServiceJob for named-pkcs11.service failed because the control process exited > with error code. See "systemctl status named-pkcs11.service" and "journalctl > -xe" for details.Failed to start named ServiceShutting down > > > > > > > > > > > > > > > > Aborting ipactl > This is what i get with "systemctl status named-pkcs11.service" > [root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● > named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native > PKCS#11 Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; > disabled; vendor preset: disabled) Active: failed (Result: exit-code) since > Tue 2016-09-20 06:28:03 EDT; 1min 2s ago Process: 3281 > ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, > status=1/FAILURE) Process: 3278 ExecStartPre=/bin/bash -c if [ ! > "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z > /etc/named.conf; else echo "Checking of zone files is disabled"; fi > (code=exited, status=0/SUCCESS) > Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal > named-pkcs11[3284]: GSSAPI Error: Unspecified GSS failure. Minor code may > provide more information (Server krbtgt/US-WEST-2.C...database)Sep 20 > 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP > error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may...er failedSep 20 06:28:03 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't > establish connection in LDAP connection pool: failureSep 20 06:28:03 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic > database 'ipa' configuration failed: failureSep 20 06:28:03 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading > configuration: failureSep 20 06:28:03 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due > to fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal > systemd[1]: named-pkcs11.service: control process exited, code=exited > status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal > systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native > PKCS#11.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal > systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:28:03 > ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service > failed. > > > > > > > > > > > > > > > > > > > > > > > > > Hint: Some lines were ellipsized, use -l to show in full. > output from "journalctl -xe" is as below: > [root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option > 'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client > step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal > named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information Sep 20 > 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP > error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal > named-pkcs11[3511]: couldn't establish connection in LDAP connection pool: > failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal > named-pkcs11[3511]: dynamic database 'ipa' configuration failed: failureSep > 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: > loading configuration: failureSep 20 06:37:00 > ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due > to fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal > systemd[1]: named-pkcs11.service: control process exited, code=exited > status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal > systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native > PKCS#11.-- Subject: Unit named-pkcs11.service has failed-- Defined-By: > systemd-- Support: > http://lists.freedesktop.org/m
[Freeipa-users] IPA Server is not coming backup
Hi All, My IPA Server was working all fine until i tried restarting it using "ipactl restart" and now i am ended with these errors :( [root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named ServiceJob for named-pkcs11.service failed because the control process exited with error code. See "systemctl status named-pkcs11.service" and "journalctl -xe" for details.Failed to start named ServiceShutting down Aborting ipactl This is what i get with "systemctl status named-pkcs11.service" [root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11 Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2016-09-20 06:28:03 EDT; 1min 2s ago Process: 3281 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, status=1/FAILURE) Process: 3278 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/US-WEST-2.C...database)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may...er failedSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't establish connection in LDAP connection pool: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic database 'ipa' configuration failed: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading configuration: failureSep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due to fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service: control process exited, code=exited status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service failed. Hint: Some lines were ellipsized, use -l to show in full. output from "journalctl -xe" is as below: [root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: couldn't establish connection in LDAP connection pool: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: dynamic database 'ipa' configuration failed: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: loading configuration: failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due to fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service: control process exited, code=exited status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.-- Subject: Unit named-pkcs11.service has failed-- Defined-By: systemd-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel-- -- Unit named-pkcs11.service has failed.-- -- The result is failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal polkitd[529]: Unregistered Authentication Agent for unix-process:3498:364279453 (system bus name :1.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal polkitd[529]: Registered Authentication Agent for
Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server [SOLVED]
On 09/19/2016 03:51 PM, Giorgos Kafataridis wrote: On 09/16/2016 06:39 PM, Petr Vobornik wrote: On 09/14/2016 07:26 PM, Giorgos Kafataridis wrote: On 09/13/2016 10:36 PM, Endi Sukma Dewata wrote: On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote: On 9/9/2016 2:46 PM, Georgios Kafataridis wrote: I've tried that but still the same result. [root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h localhost -b "uid=admin,ou=people,o=ipaca" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object Hi, The master's logs indicate there's an authentication issue. Could you search the whole directory to find the admin user? $ ldapsearch ... -b "o=ipaca" "(uid=admin)" Try also other suffixes that you have in the DS. If you find it, try to authenticate against DS directly as the admin user. If the authentication fails, try resetting the password. I believe there is actually another DS instance on CentOS 6.8 running on port 7389, so make sure you check that too. If the admin user is indeed missing, it will need to be recreated, assigned a password and certificate, and added to the appropriate groups. See also: http://pki.fedoraproject.org/wiki/IPA_PKI_Users Sorry for the delay, crazy office days. Ok, tried that and finally got a hit on the user. Indeed in 6.x you also have 7389 to look for. *Master *#ldapsearch -h localhost -p 7389 -b "o=ipaca" "(uid=admin)" -x -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=admin) # requesting: ALL # # admin, people, ipaca dn: uid=admin,ou=people,o=ipaca objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser uid: admin sn: admin cn: admin mail: root@localhost usertype: adminType userstate: 1 description: 2;6;CN=Certificate Authority,O=NELIOS;CN=ipa-ca-agent,O=NELIOS userCertificate:: MIIDaTCCAlGgAwIBAgIBBjANBgkqhkiG9w0BAQsFADAxMQ8wDQYDVQQKEwZO . . . . # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 *Replica Server* [root@ipa2-server2 ~]# ldapsearch -h ipa-server.nelios -p 7389 -b "o=ipaca" "(uid=admin)" -x -W # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=admin) # requesting: ALL # # admin, people, ipaca dn: uid=admin,ou=people,o=ipaca objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser uid: admin sn: admin cn: admin mail: root@localhost usertype: adminType userstate: 1 Password is valid in both cases. So the user is there and can be retrieved from replica, assuming that ipa-replica-install also tries 7389 the only thing I can try now is "ipa cert-request --uid admin" to create a new certificate, generate a new cacert.p12 and retry install ? In the other subthred there was a log from CentOS6 machine: /var/log/pki-ca/system 5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [6] [6] Failed to authenticate as admin UID=admin. Error: netscape.ldap.LDAPException: error result (49) 5337.TP-Processor3 - [09/Sep/2016:22:59:42 EEST] [3] [3] Servlet caGetCookie: Error getting servlet output stream when rendering template. Error Invalid Credential.. Which to me looks like a wrong password. Which indicates my original theory that IPA admin user shared with CA admin user the same password but it got out of sync. During replica installation it uses IPA admin user for authenticating as PKI admin user. If that is correct then changing PKI admin user's ( uid=admin,ou=people,o=ipaca ) password to IPA admin user's password might fix the issue. Thanks! Ok, I will look into that more. In any case, I'll keep you posted. I had to follow https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password and do it in my master and it worked at last***"ipa.ipapython.install.cli.install_tool(Replica): INFO The ipa-replica-install command was successful"!* -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE
On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > >> hi, >> >> >> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden > > Ok, how about we work around the problem. > Gladly ;-) > Since it is failing on the revocation what you might try is removing the > userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry. > > I think this will work: > > $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial > > > $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl > > If this doesn't work you can use ldapmodify to delete the usercertificate > value. > > This will remove the certificate value so there is nothing to revoke and a > new cert will be saved (hopefully). > > Now try to resubmit the request via certmonger. > > It if works then you can run ipa cert-revooke > > It isn't a great answer long-term because it is really just working around > the problem but it should get the certs renewed. > > ok, so I restarted the httpd service then I could use ipa service-show: $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial Serial Number: 175 Serial Number (hex): 0xAF bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl --- Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl" --- Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl Managed by: kdc01.unix.iriszorg.nl bash-4.1$ sudo ipa-getcert resubmit -i 20121107212513 Resubmitting "20121107212513" to "IPA". bash-4.1$ sudo getcert list Number of certificates and requests being tracked: 8. Request ID '20121107212513': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL expires: 2016-10-12 10:49:24 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib/ipa/certmonger/restart_dirsrv UNIX-IRISZORG-NL track: yes auto-renew: yes the certificate is gone: $ ipa service-show ldap/kdc01.unix.iriszorg.nl ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log' Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl Keytab: True Managed by: kdc01.unix.iriszorg.nl But then I thought, what the hell, let's try again, restarted httpd, resubmitted it, and now it did work ;-) $ ipa service-show ldap/kdc01.unix.iriszorg.nl Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl Certificate: MIIDrDCCApSgAwIBAgICAPUwDQYJKoZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDTE4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icxR6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaOBuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggrBgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4LmlyaXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZxEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO+Dwg1TzItQqXxgHtCqcQ7bmahj2AMPRNUXeZck0p/eueG4wj2kbLwTLU6cOfwnT4IOfszAS9GCql6oQIXlOfG6i6DAodBpgWziDfIrRJsJi4ZE+FvJL/ImJDdW+En50UyGp0n31oMSDIxWf1bdWUctSEYhcy9JftzkitNm1FD+a1HzeYyuHthzlHHcSIXN/kXRSGktpe8VHE5XLtKnH92vmkMnyxZvE///2+ExHXIAOkwq3ck= Keytab: True Managed by: kdc01.unix.iriszorg.nl Subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL Serial Number: 245 Serial Number (hex): 0xF5 Issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL Not Before: Tue Sep 20 08:06:58 2016 UTC Not After: Fri Sep 21 08:06:58 2018 UTC Fingerprint (MD5): f8:d3:cb:6f:4c:ca:e4:f3:47:65:51:d3:2c:69:84:df Fingerprint (SHA1): e3:0a:66:19:d7:36:fe:c4:ff:58:bf:90:35:3e:0b:31:cb:a0:58:37 So I could revoke the old one: $ ipa cert-revoke 175 Revoked: True and now getcert list shows the certificate is ok: Number of certificates and requests
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
I concede - FreeIPA is big and hard and I am new. Evidence would suggest that you know exactly what's going on under the hood. :) Thanks everyone. -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 20 September 2016 at 18:10, Alexander Bokovoy wrote: > On Tue, 20 Sep 2016, Sumit Bose wrote: > >> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote: >> >>> On Tue, 20 Sep 2016, Martin Babinsky wrote: >>> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote: >>> > > > -Original Message- >>> > > > >>> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote: >>> > > > > Hi >>> > > > > >>> > > > > Sometimes when I visit the ID Views page in the webgui, it is >>> > > > > crushingly slow, and often it times out. >>> > > > > >>> > > > > Centos 7, ipa --version >>> > > > > VERSION: 4.2.0, API_VERSION: 2.156 >>> > > > > >>> > > > > Is there a reason, can I do something to fix this? >>> > > > > >>> > > > >>> > > > What kind of ID Views do you use? Do you use them to override AD >>> users? >>> > > > Is there any useful info in '/var/log/httpd/error_log'? >>> > > >>> > > There is the single ID View Name, Default Trust View, and in that we >>> have a number of users over riding the AD usernames and home dirs. >>> > > >>> > > The httpd error log is relatively large, tbh, but there's nothing in >>> there that looks like an obvious reason. In fact, for an error log, there >>> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the >>> error log is jsonserver_session... >>> > > >>> > > Next time I see it (I only see it intermittently), I'll grab the >>> logs and have a look. >>> > > >>> > > Cheers >>> > > L. >>> > > >>> > > >>> > > >>> > > This email (including any attachments or links) may contain >>> > > confidential and/or legally privileged information and is >>> > > intended only to be read or used by the addressee. If you >>> > > are not the intended addressee, any use, distribution, >>> > > disclosure or copying of this email is strictly >>> > > prohibited. >>> > > Confidentiality and legal privilege attached to this email >>> > > (including any attachments) are not waived or lost by >>> > > reason of its mistaken delivery to you. >>> > > If you have received this email in error, please delete it >>> > > and notify us immediately by telephone or email. Peter >>> > > MacCallum Cancer Centre provides no guarantee that this >>> > > transmission is free of virus or that it has not been >>> > > intercepted or altered and will not be liable for any delay >>> > > in its receipt. >>> > > >>> > >>> > One thing that crossed my mind is to check the connectivity to the AD >>> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to >>> > contact AD DCs to do the username -> SID translation. If there is some >>> > problem contacting them, then there may be hangs/timeouts when >>> resolving >>> > override anchors. >>> Internally IPA framework attempts to resolve ID override anchors. We can >>> actually optimize this code as ipaOriginalUID attribute contains >>> normalized name already, written their when the override is created and >>> never changed afterwards. This should speed up the resolution of large >>> overrides. >>> >>> Martin, can you file a ticket for that? The code in question is >>> baseidoverride.convert_anchor_to_human_readable_form() which could >>> benefit from passing in entry_attrs and checking ipaoriginaluid there. >>> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is >>> done now. >>> >> >> As an alternative I wonder if the WebUI can be made asynchronous in the >> sense that it displays the raw data (the SID in this case) first and run >> the lookups in the background and replace the SID when the name is >> available. I've seen some Windows tools behaving this when looking up >> large numbers of SIDs. >> > We have that for external group members already. > > However, in the ID overrides there is no SID as it is. The RDN of the ID > override is 'ipaAnchorUUID' attribute which is an encoding of a target > reference. We don't need to resolve it because we already have it > resolved in 'ipaOriginalUid' attribute -- this was done to help Schema > Compatibility and SASL mapping plugins which cannot resolve > ipaAnchorUUID value. We just need to make its use consistent across the > IPA framework. > > > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
On Tue, 20 Sep 2016, Lachlan Musicman wrote: I've actually seen that on occasion - when it's loading sometimes that happens already? For external group members -- yes, not for ID overrides. See my other answer. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
On Tue, 20 Sep 2016, Sumit Bose wrote: On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote: On Tue, 20 Sep 2016, Martin Babinsky wrote: > On 09/20/2016 12:17 AM, Simpson Lachlan wrote: > > > -Original Message- > > > > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote: > > > > Hi > > > > > > > > Sometimes when I visit the ID Views page in the webgui, it is > > > > crushingly slow, and often it times out. > > > > > > > > Centos 7, ipa --version > > > > VERSION: 4.2.0, API_VERSION: 2.156 > > > > > > > > Is there a reason, can I do something to fix this? > > > > > > > > > > What kind of ID Views do you use? Do you use them to override AD users? > > > Is there any useful info in '/var/log/httpd/error_log'? > > > > There is the single ID View Name, Default Trust View, and in that we have a number of users over riding the AD usernames and home dirs. > > > > The httpd error log is relatively large, tbh, but there's nothing in there that looks like an obvious reason. In fact, for an error log, there is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the error log is jsonserver_session... > > > > Next time I see it (I only see it intermittently), I'll grab the logs and have a look. > > > > Cheers > > L. > > > > > > > > This email (including any attachments or links) may contain > > confidential and/or legally privileged information and is > > intended only to be read or used by the addressee. If you > > are not the intended addressee, any use, distribution, > > disclosure or copying of this email is strictly > > prohibited. > > Confidentiality and legal privilege attached to this email > > (including any attachments) are not waived or lost by > > reason of its mistaken delivery to you. > > If you have received this email in error, please delete it > > and notify us immediately by telephone or email. Peter > > MacCallum Cancer Centre provides no guarantee that this > > transmission is free of virus or that it has not been > > intercepted or altered and will not be liable for any delay > > in its receipt. > > > > One thing that crossed my mind is to check the connectivity to the AD > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to > contact AD DCs to do the username -> SID translation. If there is some > problem contacting them, then there may be hangs/timeouts when resolving > override anchors. Internally IPA framework attempts to resolve ID override anchors. We can actually optimize this code as ipaOriginalUID attribute contains normalized name already, written their when the override is created and never changed afterwards. This should speed up the resolution of large overrides. Martin, can you file a ticket for that? The code in question is baseidoverride.convert_anchor_to_human_readable_form() which could benefit from passing in entry_attrs and checking ipaoriginaluid there. If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is done now. As an alternative I wonder if the WebUI can be made asynchronous in the sense that it displays the raw data (the SID in this case) first and run the lookups in the background and replace the SID when the name is available. I've seen some Windows tools behaving this when looking up large numbers of SIDs. We have that for external group members already. However, in the ID overrides there is no SID as it is. The RDN of the ID override is 'ipaAnchorUUID' attribute which is an encoding of a target reference. We don't need to resolve it because we already have it resolved in 'ipaOriginalUid' attribute -- this was done to help Schema Compatibility and SASL mapping plugins which cannot resolve ipaAnchorUUID value. We just need to make its use consistent across the IPA framework. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
I've actually seen that on occasion - when it's loading sometimes that happens already? -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 20 September 2016 at 17:49, Sumit Bose wrote: > On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote: > > On Tue, 20 Sep 2016, Martin Babinsky wrote: > > > On 09/20/2016 12:17 AM, Simpson Lachlan wrote: > > > > > -Original Message- > > > > > > > > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote: > > > > > > Hi > > > > > > > > > > > > Sometimes when I visit the ID Views page in the webgui, it is > > > > > > crushingly slow, and often it times out. > > > > > > > > > > > > Centos 7, ipa --version > > > > > > VERSION: 4.2.0, API_VERSION: 2.156 > > > > > > > > > > > > Is there a reason, can I do something to fix this? > > > > > > > > > > > > > > > > What kind of ID Views do you use? Do you use them to override AD > users? > > > > > Is there any useful info in '/var/log/httpd/error_log'? > > > > > > > > There is the single ID View Name, Default Trust View, and in that we > have a number of users over riding the AD usernames and home dirs. > > > > > > > > The httpd error log is relatively large, tbh, but there's nothing in > there that looks like an obvious reason. In fact, for an error log, there > is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the > error log is jsonserver_session... > > > > > > > > Next time I see it (I only see it intermittently), I'll grab the > logs and have a look. > > > > > > > > Cheers > > > > L. > > > > > > > > > > > > > > > > This email (including any attachments or links) may contain > > > > confidential and/or legally privileged information and is > > > > intended only to be read or used by the addressee. If you > > > > are not the intended addressee, any use, distribution, > > > > disclosure or copying of this email is strictly > > > > prohibited. > > > > Confidentiality and legal privilege attached to this email > > > > (including any attachments) are not waived or lost by > > > > reason of its mistaken delivery to you. > > > > If you have received this email in error, please delete it > > > > and notify us immediately by telephone or email. Peter > > > > MacCallum Cancer Centre provides no guarantee that this > > > > transmission is free of virus or that it has not been > > > > intercepted or altered and will not be liable for any delay > > > > in its receipt. > > > > > > > > > > One thing that crossed my mind is to check the connectivity to the AD > > > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to > > > contact AD DCs to do the username -> SID translation. If there is some > > > problem contacting them, then there may be hangs/timeouts when > resolving > > > override anchors. > > Internally IPA framework attempts to resolve ID override anchors. We can > > actually optimize this code as ipaOriginalUID attribute contains > > normalized name already, written their when the override is created and > > never changed afterwards. This should speed up the resolution of large > > overrides. > > > > Martin, can you file a ticket for that? The code in question is > > baseidoverride.convert_anchor_to_human_readable_form() which could > > benefit from passing in entry_attrs and checking ipaoriginaluid there. > > If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is > > done now. > > As an alternative I wonder if the WebUI can be made asynchronous in the > sense that it displays the raw data (the SID in this case) first and run > the lookups in the background and replace the SID when the name is > available. I've seen some Windows tools behaving this when looking up > large numbers of SIDs. > > bye, > Sumit > > > > > -- > > / Alexander Bokovoy > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
On 09/20/2016 08:33 AM, Alexander Bokovoy wrote: On Tue, 20 Sep 2016, Martin Babinsky wrote: On 09/20/2016 12:17 AM, Simpson Lachlan wrote: -Original Message- On 09/19/2016 03:12 AM, Lachlan Musicman wrote: Hi Sometimes when I visit the ID Views page in the webgui, it is crushingly slow, and often it times out. Centos 7, ipa --version VERSION: 4.2.0, API_VERSION: 2.156 Is there a reason, can I do something to fix this? What kind of ID Views do you use? Do you use them to override AD users? Is there any useful info in '/var/log/httpd/error_log'? There is the single ID View Name, Default Trust View, and in that we have a number of users over riding the AD usernames and home dirs. The httpd error log is relatively large, tbh, but there's nothing in there that looks like an obvious reason. In fact, for an error log, there is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the error log is jsonserver_session... Next time I see it (I only see it intermittently), I'll grab the logs and have a look. Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. One thing that crossed my mind is to check the connectivity to the AD domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to contact AD DCs to do the username -> SID translation. If there is some problem contacting them, then there may be hangs/timeouts when resolving override anchors. Internally IPA framework attempts to resolve ID override anchors. We can actually optimize this code as ipaOriginalUID attribute contains normalized name already, written their when the override is created and never changed afterwards. This should speed up the resolution of large overrides. Martin, can you file a ticket for that? The code in question is baseidoverride.convert_anchor_to_human_readable_form() which could benefit from passing in entry_attrs and checking ipaoriginaluid there. If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is done now. Done: https://fedorahosted.org/freeipa/ticket/6339 -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow
On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote: > On Tue, 20 Sep 2016, Martin Babinsky wrote: > > On 09/20/2016 12:17 AM, Simpson Lachlan wrote: > > > > -Original Message- > > > > > > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote: > > > > > Hi > > > > > > > > > > Sometimes when I visit the ID Views page in the webgui, it is > > > > > crushingly slow, and often it times out. > > > > > > > > > > Centos 7, ipa --version > > > > > VERSION: 4.2.0, API_VERSION: 2.156 > > > > > > > > > > Is there a reason, can I do something to fix this? > > > > > > > > > > > > > What kind of ID Views do you use? Do you use them to override AD users? > > > > Is there any useful info in '/var/log/httpd/error_log'? > > > > > > There is the single ID View Name, Default Trust View, and in that we have > > > a number of users over riding the AD usernames and home dirs. > > > > > > The httpd error log is relatively large, tbh, but there's nothing in > > > there that looks like an obvious reason. In fact, for an error log, there > > > is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the > > > error log is jsonserver_session... > > > > > > Next time I see it (I only see it intermittently), I'll grab the logs and > > > have a look. > > > > > > Cheers > > > L. > > > > > > > > > > > > This email (including any attachments or links) may contain > > > confidential and/or legally privileged information and is > > > intended only to be read or used by the addressee. If you > > > are not the intended addressee, any use, distribution, > > > disclosure or copying of this email is strictly > > > prohibited. > > > Confidentiality and legal privilege attached to this email > > > (including any attachments) are not waived or lost by > > > reason of its mistaken delivery to you. > > > If you have received this email in error, please delete it > > > and notify us immediately by telephone or email. Peter > > > MacCallum Cancer Centre provides no guarantee that this > > > transmission is free of virus or that it has not been > > > intercepted or altered and will not be liable for any delay > > > in its receipt. > > > > > > > One thing that crossed my mind is to check the connectivity to the AD > > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to > > contact AD DCs to do the username -> SID translation. If there is some > > problem contacting them, then there may be hangs/timeouts when resolving > > override anchors. > Internally IPA framework attempts to resolve ID override anchors. We can > actually optimize this code as ipaOriginalUID attribute contains > normalized name already, written their when the override is created and > never changed afterwards. This should speed up the resolution of large > overrides. > > Martin, can you file a ticket for that? The code in question is > baseidoverride.convert_anchor_to_human_readable_form() which could > benefit from passing in entry_attrs and checking ipaoriginaluid there. > If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is > done now. As an alternative I wonder if the WebUI can be made asynchronous in the sense that it displays the raw data (the SID in this case) first and run the lookups in the background and replace the SID when the name is available. I've seen some Windows tools behaving this when looking up large numbers of SIDs. bye, Sumit > > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Fwd: Re: Increase ListenBacklog for httpd
Thanks Robbie for the inputs.. the load should not have been high as I have around 4000 clients with 160 users which should be manageable However, I saw a lot of clock skew too great errors in my krb5kdc.log... however I haven't been able to verify if those were genuine... Can too many clock skew errors take down the kerberos service.. On Mon, Sep 19, 2016 at 10:15 PM, Robbie Harwood wrote: > Rakesh Rajasekharan writes: > > > On Mon, Sep 12, 2016 at 10:13 AM, Rakesh Rajasekharan > > mailto:rakesh.rajasekha...@gmail.com>> > > wrote: > > > > sorry I guess I did not put the question correctly > > > > I wanted to know .. like we have the ListenBacklog for apache to > > basically define the number of connections it can handle.. do we > > have some thing similar for our krb5kdc service.. as the SYN floodin > > at 88 looks like krb5kdc service is not able to handle sudden spurt > > in connections or the number of connections are more than it could > > handle.. > > > > So, would be great if I could know how many connection it can > > support at any given time ..most of the times I see this error while > > i add clients to IPA master.. so if thers a known limit , I could > > first check netstat to see how many connections I have at any point > > and if its below the limit only then setup ipa-client-install > > We intentionally do not have such a parameter in krb5. We call > listen(5) internally, but please note this is probably not the parameter > you want to be able to tune. > > The listen() backlog is the number of connections that are waiting to be > accept()ed by the process. They sit in the kernel, not receiving > SYNACK. This number does not count connections that the process - here > krb5kdc - has accept()ed and is currently processing. > > If you're truly seeing connections faster than they can be accept()ed, > you have a load problem that tuning this parameter likely won't fix. > You should probably configure replicas: krb5 will fall back if the > connection is refused from one kdc to the next configured one. This > will result in faster operation for your users than waiting on an > enormous listen() backlog will as well. > > A tunable for the listen value may be added in the future, but is not > available at the present time. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd.conf - the server and host-client relationship
On (20/09/16 15:06), Lachlan Musicman wrote: >Hola, > >What is the relationship between the IPA server, host-clients and the >sssd.conf? > >>From what I can tell, sssd.conf is edited/changed by the ipa-client-install >process on the host-client. > >What level of similarity does there need to be between the two sssd.confs? > >My server's sssd.conf has a significant number of extra parameters set that >are not getting put onto the clients. > >Debug levels are the most obvious, and understandable, omissions - but some >others are frustrating. > >The (non debug_level) parameters missing are: >-- >[domain/unixdev.etc] >ignore_group_members = True It was probably set as a result of performance tuning. >ldap_purge_cache_timeout = 0 That's default since 1.13.0 >subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout that's specific option for sssd on IPA server >selinux_provider = none It was probably set as a workaround of bug which have been already fixed. >ipa_server_mode = True that's specific option for sssd on IPA server >sudo_provider = ldap >ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au >ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au >ldap_sasl_mech = GSSAPI >ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au >ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU >krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au Previous 7 options are not required since sssd-1.10 > >[sssd] >config_file_version = 2 >domains = unixdev.etc > >[nss] >memcache_timeout = 600 This option is se by ipa-*-install on ipa server mode. >-- > >The other diff is that the > >host has: ipa_server = vmdv-linuxidm1.unixdev.petermac.org.au >client has: ipa_server = _srv_, vmdv-linuxidm1.unixdev.petermac.org.au > >Which I presume is expected/desired. > >And the reason I ask is because we have selinux disabled, and without the Do you eman disabled or permissive? BTW freeIPA works well with SELinux in enforcing mode >"selinux_provider = none" line, we would get kicked out as soon as freeipa >had logged us in with message: > disabled SELinux should not affected authentication; but I didn't test that. >Connection to test_client.unixdev.petermac.org.au closed by remote host. > >and on that host-client there was a brand new selinux_child.log that I'd >never seen before. > LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Issues with FreeIPA SSH Key authentication
Thank you Lukas. The issue , not being able to login to some servers in our setup with ssh keys, was due to incorrect permissions on /usr directory,per the following entry in /var/log/secure. *sshd[12856]: error: bad ownership or modes for AuthorizedKeysCommand path component "/usr"* After setting up the permissions for /usr to 755, I was able to login to these servers with ssh private keys. Thank you again,Lukas, for your help. Regards Venkataramana On Fri, Sep 16, 2016 at 11:51 AM, Lukas Slebodnik wrote: > On (15/09/16 11:46), Venkataramana Kintali wrote: > >Hi Lukas, > >ssh_config is also same on all servers. > >Our need is to do it both ways, to be able to login with ssh public > >keys(uploaded in IPA) and disable password login, and be able to access > >allhosts within the same IPA domain silently from any host. > >Hoping the configs will help, I am including the configurations here. > > > >ssh_config file : http://pastebin.com/MWHyH1Qw > >sshd_config file: http://pastebin.com/gpn5XhXM > >sssd_config file: http://pastebin.com/5Pby6xKp > > > Looks good to me > > >I just used some placeholders for sssd_config file in pastebin instead of > >actual values. > > > > In initial mail you wrote: > >I am able to login to some IPA clients but not able to login to other IPA > >clients with putty using private key and passphrase. > Therefore your previous test case is wrong. > If you want to test authentication with public keys > then you cannot obtain krb5 ticket with kinit. > > I would also recommend to call kdestory before > authentication with ssh to be sure that gssapi > authentication will not be used. > > I would recomment to set "debug_level = 7" in domain and ssh section > on the server where you woudl like to authenticate. > then restart sssd and try to authenticate with ssh + verbose mode > e.g. ssh -v u...@remote.host > > Then I would recommend to compare logs from working server > and from broken server. > > LS > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project