Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
I also looked at RUVs and here is what I found. I do not know if anything here is helpful. ldapsearch -ZZ -h ipa11.mgmt.crosschx.com -D "cn=Directory Manager" -W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsds50ruv\|nsDS5ReplicaId" nsDS5ReplicaId: 1095 nsds50ruv: {replicageneration} 583445980060 nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389} 5865323f04470 nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389} 58651fdb0056000 nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389} 5834459c006 nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389} 58344997005b000 nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389} 583445c30061000 nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389} 586529560051000 IPA12 - this is the problem node. ldapsearch -ZZ -h ipa12.mgmt.crosschx.com -D "cn=Directory Manager" -W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsds50ruv\|nsDS5ReplicaId" nsDS5ReplicaId: 81 nsds50ruv: {replicageneration} 583445980060 nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389} 586529560051000 nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389} 5834459c006 nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389} 58651fdb0056000 nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389} 58344997005b000 nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389} 583445c30061000 ldapsearch -ZZ -h ipa13.mgmt.crosschx.com -D "cn=Directory Manager" -W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsds50ruv\|nsDS5ReplicaId" nsDS5ReplicaId: 86 nsds50ruv: {replicageneration} 583445980060 nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389} 58651fdb0056000 nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389} 5865323f04470 nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389} 5834459c006 nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389} 58344997005b000 nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389} 583445c30061000 nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389} 586529560051000 *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* 614.427.2411 mike.plemm...@crosschx.com www.crosschx.com On Wed, May 3, 2017 at 10:52 PM, Michael Plemmons < michael.plemm...@crosschx.com> wrote: > I ran another test. I started IPA with the ignore service failure option > and I tired doing ldap searches like this. > > ldapsearch -H ldaps://ipa12.mgmt.crosschx.com > > from both my laptop and from ipa11.mgmt and I get successful returns when > logging in as the admin user and as the directory manager. > > I then looked closer at the LDAP access logs for the last time I tried to > start up PKI and got the auth failure and i see this. > > > [04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL > connection from 10.71.100.92 to 10.71.100.92 > [04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES > [04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn="" > method=sasl version=3 mech=EXTERNAL > [04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97 > nentries=0 etime=0 > > Is dn="" supposed to be empty? > > > > > > > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* > 614.427.2411 > mike.plemm...@crosschx.com > www.crosschx.com > > On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons < > michael.plemm...@crosschx.com> wrote: > >> I realized that I was not very clear in my statement about testing with >> ldapsearch. I had initially run it without logging in with a DN. I was >> just running the local ldapsearch -x command. I then tested on ipa12.mgmt >> and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory >> Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch >> command succeeded. >> >> I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user. I >> also ran the command showing a line count for the output and the line >> counts for each were the same when run from ipa12.mgmt and ipa11.mgmt. >> >> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b >> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn >> >> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w >> PASSWORD dn >> >> >> >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* >> 614.427.2411 >> mike.plemm...@crosschx.com >> www.crosschx.com >> >> On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons < >> michael.plemm...@crosschx.com> wrote: >> >>> I have a three node IPA cluster. >>> >>> ipa11.mgmt - was a master over 6 months ago >>> ipa13.mgmt - current master >>> ipa12.mgmt >>> >>> ipa13 has agreements with ipa11 and ipa12. ipa11 and ipa12 do not have >>> agreements between each other. >>> >>> It appears that either ipa12.mgmt lost some level of its replicati
Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
I ran another test. I started IPA with the ignore service failure option and I tired doing ldap searches like this. ldapsearch -H ldaps://ipa12.mgmt.crosschx.com from both my laptop and from ipa11.mgmt and I get successful returns when logging in as the admin user and as the directory manager. I then looked closer at the LDAP access logs for the last time I tried to start up PKI and got the auth failure and i see this. [04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL connection from 10.71.100.92 to 10.71.100.92 [04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES [04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97 nentries=0 etime=0 Is dn="" supposed to be empty? *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* 614.427.2411 mike.plemm...@crosschx.com www.crosschx.com On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons < michael.plemm...@crosschx.com> wrote: > I realized that I was not very clear in my statement about testing with > ldapsearch. I had initially run it without logging in with a DN. I was > just running the local ldapsearch -x command. I then tested on ipa12.mgmt > and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory > Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch > command succeeded. > > I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user. I > also ran the command showing a line count for the output and the line > counts for each were the same when run from ipa12.mgmt and ipa11.mgmt. > > ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b > "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn > > ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w > PASSWORD dn > > > > > > > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* > 614.427.2411 > mike.plemm...@crosschx.com > www.crosschx.com > > On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons < > michael.plemm...@crosschx.com> wrote: > >> I have a three node IPA cluster. >> >> ipa11.mgmt - was a master over 6 months ago >> ipa13.mgmt - current master >> ipa12.mgmt >> >> ipa13 has agreements with ipa11 and ipa12. ipa11 and ipa12 do not have >> agreements between each other. >> >> It appears that either ipa12.mgmt lost some level of its replication >> agreement with ipa13. I saw some level because users / hosts were >> replicated between all systems but we started seeing DNS was not resolving >> properly from ipa12. I do not know when this started. >> >> When looking at replication agreements on ipa12 I did not see any >> agreement with ipa13. >> >> When I run ipa-replica-manage list all three hosts show has master. >> >> When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica. >> >> When I run ipa-replica-manage ipa12.mgmt nothing returned. >> >> I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt >> ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt >> >> I then ran the following >> >> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com >> >> ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com >> >> I was still seeing bad DNS returns when dig'ing against ipa12.mgmt. I >> was able to create user and DNS records and see the information replicated >> properly across all three nodes. >> >> I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt >> because I wanted to make sure everything was running fresh after the >> changes above. While IPA was staring up (DNS started) we were able to see >> valid DNS queries returned but pki-tomcat would not start. >> >> I am not sure what I need to do in order to get this working. I have >> included the output of certutil and getcert below from all three servers as >> well as the debug output for pki. >> >> >> While the IPA system is coming up I am able to successfully run >> ldapsearch -x as the root user and see results. I am also able to login >> with the "cn=Directory Manager" account and see results. >> >> >> The debug log shows the following error. >> >> >> [03/May/2017:21:22:01][localhost-startStop-1]: >> >> [03/May/2017:21:22:01][localhost-startStop-1]: = DEBUG SUBSYSTEM >> INITIALIZED === >> [03/May/2017:21:22:01][localhost-startStop-1]: >> >> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at >> autoShutdown? false >> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown >> crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb >> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look >> for cert for auto-shutdown support:auditSigningCert cert-pki-ca >> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found >> cert:auditSigningCert cert-pki-ca >> [03/May/2017:21:22:01][localhost-startStop-1
Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
I realized that I was not very clear in my statement about testing with ldapsearch. I had initially run it without logging in with a DN. I was just running the local ldapsearch -x command. I then tested on ipa12.mgmt and ipa11.mgmt logging in with a full DN for the admin and "cn=Directory Manager" from ipa12.mgmt (broken server) and ipa11.mgmt and both ldapsearch command succeeded. I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user. I also ran the command showing a line count for the output and the line counts for each were the same when run from ipa12.mgmt and ipa11.mgmt. ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "DN" -w PASSWORD -b "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w PASSWORD dn *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* 614.427.2411 mike.plemm...@crosschx.com www.crosschx.com On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons < michael.plemm...@crosschx.com> wrote: > I have a three node IPA cluster. > > ipa11.mgmt - was a master over 6 months ago > ipa13.mgmt - current master > ipa12.mgmt > > ipa13 has agreements with ipa11 and ipa12. ipa11 and ipa12 do not have > agreements between each other. > > It appears that either ipa12.mgmt lost some level of its replication > agreement with ipa13. I saw some level because users / hosts were > replicated between all systems but we started seeing DNS was not resolving > properly from ipa12. I do not know when this started. > > When looking at replication agreements on ipa12 I did not see any > agreement with ipa13. > > When I run ipa-replica-manage list all three hosts show has master. > > When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica. > > When I run ipa-replica-manage ipa12.mgmt nothing returned. > > I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt > ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt > > I then ran the following > > ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com > > ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com > > I was still seeing bad DNS returns when dig'ing against ipa12.mgmt. I was > able to create user and DNS records and see the information replicated > properly across all three nodes. > > I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt > because I wanted to make sure everything was running fresh after the > changes above. While IPA was staring up (DNS started) we were able to see > valid DNS queries returned but pki-tomcat would not start. > > I am not sure what I need to do in order to get this working. I have > included the output of certutil and getcert below from all three servers as > well as the debug output for pki. > > > While the IPA system is coming up I am able to successfully run ldapsearch > -x as the root user and see results. I am also able to login with the > "cn=Directory Manager" account and see results. > > > The debug log shows the following error. > > > [03/May/2017:21:22:01][localhost-startStop-1]: > > [03/May/2017:21:22:01][localhost-startStop-1]: = DEBUG SUBSYSTEM > INITIALIZED === > [03/May/2017:21:22:01][localhost-startStop-1]: > > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at > autoShutdown? false > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown > crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look > for cert for auto-shutdown support:auditSigningCert cert-pki-ca > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found > cert:auditSigningCert cert-pki-ca > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init > id=debug > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized > debug > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem > id=log > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init > id=log > [03/May/2017:21:22:01][localhost-startStop-1]: Creating > RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit) > [03/May/2017:21:22:01][localhost-startStop-1]: Creating > RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system) > [03/May/2017:21:22:01][localhost-startStop-1]: Creating > RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions) > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at > autoShutdown? false > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown > crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look > for cert for auto-shutdown support:auditSigningCert cert-pki-ca > [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found > cert:auditSigningCert cert-pki-ca > [03/May/2017:21:22:01][localhost
Re: [Freeipa-users] External cert with correct CSR?
On Tue, May 02, 2017 at 11:10:12AM -0500, Kat wrote: > Yeah, after I sent this email, I realized what I was trying to do and that, > "Oh wait, this is not really going to work." > Indeed. This feature is usually used to chain an IPA CA into an organisation's existing PKI, which is controlled by the organisation, thus they can add whatever they need to the cert regardless of what is/is not asserted by the CSR). Cheers, Fraser > For what it is worth - version on RHEL 7.3 - 4.4.0-14.el7_3.7 > > -K > > On 5/2/17 11:04 AM, Rob Crittenden wrote: > > Kat wrote: > > > Hi all, > > > > > > I am somewhat confused trying to get the process of using an external > > > cert for IPA. > > > > > > If I follow step 1: > > > ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.COM > > > --external-ca -U > > > > > > This does indeed generate a CSR, but trying to do anything with this CSR > > > has no success since it is not properly formed with all info. In > > > otherwords, ipa does not add country, state, location, etc. If I submit > > > this CSR to any cert company, it will of course, complain. Is there a > > > way to get this right? Or am I just missing something here? > > > > > What cert company are you trying to get to sign this? This is a CA cert, > > I don't know that any of the major ones will sign this, at least not > > without a huge check. > > > > What version of IPA? > > > > 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
[Freeipa-users] ipa server-del
Is there any way this can be made to work? This server does not exist in real life or seemingly in FreeIPA, but a ghost of it does. ianh@vm-ian-laptop:~$ ipa server-find freeipa-dal.bpt.rocks 1 IPA server matched Server name: freeipa-dal.bpt.rocks Min domain level: 0 Max domain level: 0 Number of entries returned 1 ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force --continue Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: WARNING: Forcing removal of freeipa-dal.bpt.rocks - Deleted IPA server "" - Failed to remove: freeipa-dal.bpt.rocks ianh@vm-ian-laptop:~$ - Ian -- 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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
I have a three node IPA cluster. ipa11.mgmt - was a master over 6 months ago ipa13.mgmt - current master ipa12.mgmt ipa13 has agreements with ipa11 and ipa12. ipa11 and ipa12 do not have agreements between each other. It appears that either ipa12.mgmt lost some level of its replication agreement with ipa13. I saw some level because users / hosts were replicated between all systems but we started seeing DNS was not resolving properly from ipa12. I do not know when this started. When looking at replication agreements on ipa12 I did not see any agreement with ipa13. When I run ipa-replica-manage list all three hosts show has master. When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica. When I run ipa-replica-manage ipa12.mgmt nothing returned. I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt ipa12.mgmt.crosschx.com ipa13.mgmt.crosschx.com on ipa12.mgmt I then ran the following ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com I was still seeing bad DNS returns when dig'ing against ipa12.mgmt. I was able to create user and DNS records and see the information replicated properly across all three nodes. I then ran ipactl stop on ipa12.mgmt and then ipactl start on ipa12.mgmt because I wanted to make sure everything was running fresh after the changes above. While IPA was staring up (DNS started) we were able to see valid DNS queries returned but pki-tomcat would not start. I am not sure what I need to do in order to get this working. I have included the output of certutil and getcert below from all three servers as well as the debug output for pki. While the IPA system is coming up I am able to successfully run ldapsearch -x as the root user and see results. I am also able to login with the "cn=Directory Manager" account and see results. The debug log shows the following error. [03/May/2017:21:22:01][localhost-startStop-1]: [03/May/2017:21:22:01][localhost-startStop-1]: = DEBUG SUBSYSTEM INITIALIZED === [03/May/2017:21:22:01][localhost-startStop-1]: [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=debug [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized debug [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem id=log [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init id=log [03/May/2017:21:22:01][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit) [03/May/2017:21:22:01][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system) [03/May/2017:21:22:01][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions) [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=log [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized log [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem id=jss [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init id=jss [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=jss [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized jss [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init id=dbs [03/May/2017:21:22:01][localhost-startStop-1]: DBSubsystem: init() mEnableSerialMgmt=true [03/May/2017:21:22:01][localhost-startStop-1]
[Freeipa-users] Password history based on age, not count?
Would it be reasonable to request a feature for FreeIPA to enforce password history reuse based on age, instead of a count? Meaning configure FreeIPA to enforce that a password cannot be reused within the last 1 year? Then we could remove the minimum time between password changes, and not worry about people cycling through X passwords to be able to reuse one. When we were using OpenLDAP for user account management, I wrote an extension for it to do just that and it was rather convenient (not having to deal with an annoying min-change-time). The whole min-time-between-changes, and number-of-passwords-in-history thing has always seemed like a hack to accomplish the true goal of preventing users from reusing passwords within a certain amount of time. -Patrick -- 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] CA lost on migration
Hi, I have migrated some FreeIPA servers from 3.0.0-51 to 4.4.0-14 by adding new replicas. There were a lot of issues, and I'm strugglig a bit with a configuration management system set up by a central IT department, which overrides files like sssd.conf, and I have to make exceptions to the policy. I hope someone could take the time to help me with this anyway. I was able to join both new RHEL 7 machines, and remove one of the old RHEL 6 machines, but then I couldn't remove the last one, and couldn't install the CA on any of the new masters. I (perhaps stupidly) removed the old server using ldapdelete, based on this thread: https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html. I thought that if I could get rid of the old stuff, I may be able to successfully promote one of the new servers to CA master. The command to install the CA almost completed successfully on the first master, but stopped on one of the last steps. Now I get: # ipa-ca-install CA is already installed on this host. It is clear that the CA is not installed. I get errors in /var/log/httpd/error_log for hosts requesting certs, and getting NotFound. ipa: INFO: [xmlserver] host/x@DOMAIN: cert_request(u'MIIDnzCCaoc... I then removed and uninstalled the other master, which did not have a CA, thinking it could get going with a reinstall. However, the installation fails ipa : ERROR Cannot issue certificates: a CA is not installed. Use the --http-cert-file, --dirsrv-cert-file options to provide custom certificates. (there may be some typos in the error messages, since I'm copying from an air-gapped network) Is there any way I can manually resurrect the CA? I have the files left over on the original (version 3) master, but did do an uninstall. If that's not possible, is there any way to migrate the users to a new domain with exactly the same name (this would be less convenient, if it's actually possible, since I have to re-enroll all the clients). Thanks, Marius Bjørnstad -- 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] Can't make replica with CA due to LDAP 'replication manager' user not found error
Any guidance for this one? Summary - this seems to be the fatal error that causes the CA setup on the replica to fail: May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: The specified user cn=Replication Manager masterAgreement1-usaeilidmp002.XXX.org-pki-tomcat,cn=config does not exist May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. More details ... Trying to build a replica with CA duties for the first time. It hangs here during the replica install process: ipa : DEBUGstderr= ipa : DEBUGwait_for_open_ports: localhost [8080, 8443] timeout 300 ipa : DEBUGWaiting until the CA is running ipa : DEBUGrequest POST http://usaeilidmp002.XXX.org:8080/ca/admin/ca/getStatus ipa : DEBUGrequest body '' However the root cause seems to be that the CA won't start because something is wrong with an LDAP replication manager user? When I restart the pki-tomcatd service the replica install STDOUT refreshes the above status. After the 3rd attempt it triggers the fatal "CA will not start after 300 seconds" error From the logs: # systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-05-03 15:09:04 UTC; 40s ago Process: 3843 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=1/FAILURE) Process: 3880 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, status=0/SUCCESS) Main PID: 3993 (java) CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service └─3993 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -DRESTEASY_LIB=/usr/share/java/resteasy-base -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/... May 03 15:09:08 usaeilidmp002.XXX.org server[3993]: SSLAuthenticatorWithFallback: Setting container May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: SSLAuthenticatorWithFallback: Initializing authenticators May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: SSLAuthenticatorWithFallback: Starting authenticators May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine.initializePasswordStore() begins May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine.initializePasswordStore(): tag=internaldb May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection connecting to usaeilidmp002.XXX.org:389 May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine.initializePasswordStore(): tag=replicationdb May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection connecting to usaeilidmp002.XXX.org:389 May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: The specified user cn=Replication Manager masterAgreement1-usaeilidmp002.XXX...not exist May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not...noring .. Hint: Some lines were ellipsized, use -l to show in full. -- 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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
It turns out we had another 16.04 machine which was working fine. But as soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 1.8.16-0ubuntu1.3, it stopped working too. So it looks like I have a reproducing case for this and I can investigate further - I suspect it's a behaviour change from this fix: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 -- 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] GSSAPI authentication from trusted AD domain
Tickets on the FreeIPA host after connecting (with a password): [adm.tie...@clients.rdmedia.com@neodymium ~]$ klist Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1 Default principal: adm.tie...@clients.rdmedia.com Valid starting Expires Service principal 05/03/2017 11:26:03 05/03/2017 21:26:03 krbtgt/ clients.rdmedia@clients.rdmedia.com renew until 05/04/2017 11:26:03 Tickets on the AD laptop after a connection attempt: C:\Users\adm.tiemen.CLIENTS>klist Current LogonId is 0:0x587aa Cached Tickets: (2) #0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e1 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 5/3/2017 11:12:46 (local) End Time: 5/3/2017 21:12:46 (local) Renew Time: 5/10/2017 11:12:46 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: vm-win-01.clients.rdmedia.com #1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @ CLIENTS.RDMEDIA.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a5 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 5/3/2017 11:12:46 (local) End Time: 5/3/2017 21:12:46 (local) Renew Time: 5/10/2017 11:12:46 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: vm-win-01.clients.rdmedia.com On 2 May 2017 at 19:45, Tiemen Ruiten wrote: > It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need > for mapping. However on the AD host: > > Microsoft Windows [Version 6.3.9600] > > (c) 2013 Microsoft Corporation. All rights reserved. > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist > > > Current LogonId is 0:0x603b58 > > > Cached Tickets: (0) > > > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen> > > Note that this is the domain controller and I'm logged in using the > experimental Win32-OpenSSH server. Not sure if that makes a difference. I > am not currently in the office, so unfortunately can't turn on the only > joined laptop in this domain. > > How can I ensure a proper ticket is generated? > > On 2 May 2017 at 18:25, Sumit Bose wrote: > >> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote: >> > I think I just realised that my expectation may be wrong: GSSAPI login >> with >> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it >> > correct to also expect passwordless login with an AD user to a FreeIPA >> host? >> >> The AD user case should work as well. >> >> First please send the SSSD version you use on the IPA client, >> alternatively you can check if >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This >> would tell if SSSD can map the user name to the Kerberos principal of if >> additional configuration is needed. >> >> On the AD host please check after trying to connect with ssh if there is >> a proper service ticket for the IPA client by calling 'klist' in cmd.exe >> or PowerShell. >> >> bye, >> Sumit >> >> > >> > On 2 May 2017 at 17:40, Jason B. Nance wrote: >> > >> > > Hi Tiemen, >> > > >> > > To be clear, what I'm trying to do: log in from an AD account >> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA >> > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I >> > > expect to be logged in through GSSAPI, instead I get a password >> prompt. >> > > >> > > I'm assuming that you are coming from a Windows client that is domain >> > > joined and logged into that Windows client with the same domain >> credentials >> > > that you are using to connect to the IPA-joined host. Do you also >> have >> > > your SSH client configured to attempt GSSAPI? It appears that you do >> from >> > > the logs you provided but I'm just double-checking. >> > > >> > > In my setup I've found that this feature does not work all of the >> time. >> > > I've not yet been able to track it down and I'm assuming it has >> something >> > > to do with connections to domain controllers timing out, but at this >> point >> > > that is speculation. >> > > >> > > So to answer your question, yes, that should work. Sorry I don't have >> > > more information for you, I guess I'm basically "me too"ing your post. >> > > >> > > Regards, >> > > >> > > j >> > > >> > > Is this supposed to work? Did I miss something? >> > > >> > > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: >> > > >> > > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK >> > > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. >> > > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: >> entering fd >> > > = 8 config len 922 >> > > May 2 17:10
Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
> do you have 'sudo: files sss" or "sudoers: files sss"? The former doesn't do anything, the latter is correct. My mistake, I meant sudoers: files sss But oddly, out of the three 16.04 boxes I set up and enrolled, it was missing on one of them - and this happened to be the one I was checking logs on :-( (However, sudo fails in the same way on all three machines) So after adding this I've rechecked logs. /var/log/sudo-debug is the same, in particular it still shows "policy plugin returns 0" and nothing after. With sss_debuglevel 5, /var/log/sssd/sssd_IPA.EXAMPLE.COM.log has ... (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): ruser: brian.candler (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): rhost: (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): priv: 0 (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): cli_pid: 22709 (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] (0x0100): logon name: not set (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [ipa_hostgroup_info_done] (0x0200): Dereferenced host group: normal_hosts (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [ipa_hostgroup_info_done] (0x0200): Dereferenced host group: development_hosts (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_normal_hosts] (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [be_pam_handler_callback] (0x0100): Sending result [0][IPA.EXAMPLE.COM] (Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [be_pam_handler_callback] (0x0100): Sent result [0][IPA.EXAMPLE.COM] ("allow_normal_hosts" is indeed the name of the rule in FreeIPA database) sssd.log has: (Wed May 3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed May 3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed May 3 08:50:35 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Wed May 3 08:50:35 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [root] from [] (Wed May 3 08:50:35 2017) [sssd[nss]] [nss_cmd_initgroups_search] (0x0080): No matching domain found for [root], fail! (Wed May 3 08:50:37 2017) [sssd[nss]] [client_recv] (0x0200): Client disconnected! (Hmm, suspicious that error about "root" ??) sssd_sudo.log has: (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'brian.candler' matched without domain, user is brian.candler (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'brian.candler' matched without domain, user is brian.candler (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [brian.candler] from [] (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [brian.cand...@ipa.example.com] (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=brian.candler)(sudoUser=#121103)(sudoUser=%security_administrators)(sudoUser=%admins)(sudoUser=%network_readonly)(sudoUser=%vpn)(sudoUser=%system_administrators)(sudoUser=%ipausers)(sudoUser=%staff)(sudoUser=%brian.candler)(sudoUser=+*))(&(dataExpireTimestamp<=1493801435)))] (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'brian.candler' matched without domain, user is brian.candler (Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'brian.candler' matched without domain, user is brian.candler (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [brian.candler] from [] (Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [brian.
Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
On Wed, May 03, 2017 at 09:04:05AM +0100, Brian Candler wrote: > Hi, > > I have FreeIPA set up under CentOS 7. When I use freeipa-client to add an > ubuntu 14.04 client it works fine (*). However when do the same with ubuntu > 16.04, sudo always refuses to run: > > $ sudo -s > [sudo] password for brian.candler: > brian.candler is not allowed to run sudo on api-dev.int.example.com. This > incident will be reported. > > I have a simple one-entry sudo policy which says that for all users in > groups X and Y, on all hosts, run all commands. (**) > > If I crank up sudo logging by setting this in /etc/sudo.conf: > > Debug sudo /var/log/sudo-debug all@info > > then on the working 14.04 machine I see > > ... various settings ... > May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/ > May 2 22:05:27 sudo[19175] user_info: user=brian.candler > May 2 22:05:27 sudo[19175] user_info: pid=19175 > ... lots more user_info, perms, netgroups etc ... > May 2 22:05:29 sudo[19175] policy plugin returns 1 > ... > > but on the failing 16.04 machine I see only this: > > May 3 07:44:56 sudo[21118] will restore signal 13 on exec > May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ > sudo_ttyname_dev() ./ttyname.c:336 > May 3 07:44:56 sudo[21118] settings: run_shell=true > May 3 07:44:56 sudo[21118] settings: progname=sudo > May 3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0 > :::::230/::::::: > fe80::1:::/::::: > May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/ > May 3 07:44:58 sudo[21118] policy plugin returns 0 > > That's all that gets logged - nothing more. It seems that a return of 0 > means failure: > > https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html > > "open() > ... > Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if > there was a usage error." > > But I have no idea what sort of failure or why. > > /var/log/auth.log shows: > > May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure; > logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 > ruser=brian.candler rhost= user=brian.candler > May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success; > logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 > ruser=brian.candler rhost= user=brian.candler > May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; > TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash > > (which shows I gave the correct FreeIPA password, but not why the sudoers > lookup failed) > > I really can't see where else to look. Both machines have "sudo: files sss" > in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf. Setting > "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious > errors. do you have 'sudo: files sss" or "sudoers: files sss"? The former doesn't do anything, the latter is correct. if you crank up debugging in the sudo section in sssd.conf do you see any activity at all? do you have '/usr/lib64/libsss_sudo.so' installed? On fedora/rhel, this is provided by libsss_sudo, I don't know what provides it on Debian. > > I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from > https://www.sudo.ws/download.html, but this makes no difference. > > Has anyone seen this problem before, or have some ideas where else to look? > > Thanks, > > Brian Candler. > > > (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services: > > |[sssd]| > |services = nss, pam, ssh, sudo| > > but this was done automatically by freeipa-client in Ubuntu 16.04. > > (**) Therefore I'm pretty sure this is not the netgroups problem, for which > the fix has been released anyway: > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 > -- > 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] LDAP size limit and the FreeIPA web UI
On 05/02/2017 10:50 PM, Jay Fenlason wrote: One of my users is having trouble because the FreeIPA web interface does not work well with a DNS zone that contains more than 2000 entries. When he goes to Network Services->DNS->DNS Zones and selects the problematic zone, he gets an error popup saying the results were truncated because the number of entries exceeds the LDAP server's search limit. I went in to IPA Server->Configuration and changed the Search size limit, but raising it over 2000 requires manually modifying the LDAP server configuration. Are there any plans to improve the web UI so that it does not require such a large size limit when viewing a DNS zone? Are there other GUI tools that can be used to view/edit the DNS zone data (and that don't also suffer from hitting these search size limits)? I'm using ipa-server-4.4.0-14.el7.centos.6.x86_64 if it matters. -- JF Web UI has the same size limits which are imposed by LDAP server for the authenticated user. In 4.5 version the warning was changed to be less annoying. There are currently no specific plans to change Web UI in this area. A think which was considered is to disable paging for post pages (e.g. user and host search) and rely more on size-limits and searching. The reasoning is that browser through a lot of records is not very usable and it is better to search. So I would ask in different way. How would you envision the Web UI should behave for so many records? E.g. just in DNS area. -- Petr Vobornik -- 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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
Hi, I have FreeIPA set up under CentOS 7. When I use freeipa-client to add an ubuntu 14.04 client it works fine (*). However when do the same with ubuntu 16.04, sudo always refuses to run: $ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. I have a simple one-entry sudo policy which says that for all users in groups X and Y, on all hosts, run all commands. (**) If I crank up sudo logging by setting this in /etc/sudo.conf: Debug sudo /var/log/sudo-debug all@info then on the working 14.04 machine I see ... various settings ... May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/ May 2 22:05:27 sudo[19175] user_info: user=brian.candler May 2 22:05:27 sudo[19175] user_info: pid=19175 ... lots more user_info, perms, netgroups etc ... May 2 22:05:29 sudo[19175] policy plugin returns 1 ... but on the failing 16.04 machine I see only this: May 3 07:44:56 sudo[21118] will restore signal 13 on exec May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() ./ttyname.c:336 May 3 07:44:56 sudo[21118] settings: run_shell=true May 3 07:44:56 sudo[21118] settings: progname=sudo May 3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/ May 3 07:44:58 sudo[21118] policy plugin returns 0 That's all that gets logged - nothing more. It seems that a return of 0 means failure: https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html "open() ... Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error." But I have no idea what sort of failure or why. /var/log/auth.log shows: May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 ruser=brian.candler rhost= user=brian.candler May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 ruser=brian.candler rhost= user=brian.candler May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash (which shows I gave the correct FreeIPA password, but not why the sudoers lookup failed) I really can't see where else to look. Both machines have "sudo: files sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf. Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious errors. I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from https://www.sudo.ws/download.html, but this makes no difference. Has anyone seen this problem before, or have some ideas where else to look? Thanks, Brian Candler. (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services: |[sssd]| |services = nss, pam, ssh, sudo| but this was done automatically by freeipa-client in Ubuntu 16.04. (**) Therefore I'm pretty sure this is not the netgroups problem, for which the fix has been released anyway: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 -- 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