From ftweedal at redhat.com Sun Nov 1 22:43:32 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 2 Nov 2015 08:43:32 +1000 Subject: [Freeipa-users] FreeIPA dogtag pkinit In-Reply-To: <20151030140256.GA981@p.redhat.com> References: <56323371.5020800@nbs-system.com> <20151030140256.GA981@p.redhat.com> Message-ID: <20151101224332.GH20018@dhcp-40-8.bne.redhat.com> On Fri, Oct 30, 2015 at 03:02:56PM +0100, Sumit Bose wrote: > On Thu, Oct 29, 2015 at 03:55:45PM +0100, Jean 'clark' EYMERIT wrote: > > Hello, > > > > I search a way to use pkinit > > (http://web.mit.edu/kerberos/krb5-devel/doc/admin/pkinit.html) with > > FreeIPA (even without dogtag). > > > > Can someone give me a howto for this ? > > I can follow the steps described in the MIT pkinit instructions from > above. Besides creating the needed certificates you only have to modify > krb5.conf on the IPA server and client. The kadmin steps are not needed > here because pre-authentication is already requeired for all IPA users. > > > > > On the official documentation and the ML archive, I only find some > > references about the disabled feature because of the dogtag incompatibility. > > yes, this was mainly done because there are special requirements on the > certificates as can been seen from the MIT document, which where hard to > meet to at the time. > > With the latest version of FreeIPA we now have certificate profiles > which should allow an automatic pkinit setup in future versions of IPA. > My plan is to check what is needed here during the next weeks. > We support the Krb5PrincipalName OtherName SAN already, even in the default profile**. It must be included in the PKCS #10 CSR (per instructions at MIT page above) and values are validated by FreeIPA before passing to Dogtag. ** Key Usage / Extended Key Usage would probably not be appropriate for user certs, though. There's a ticket for "CSR templates"[1] to make doing this sort of thing easier. Eventually I would like to have profiles that don't need any special info in the CSR but just read data from the directory. [1] https://fedorahosted.org/freeipa/ticket/4899 Cheers, Fraser > HTH > > bye, > Sumit > > > > > Some links after my search : > > https://github.com/encukou/freeipa/blob/master/ipalib/plugins/pkinit.py > > https://www.redhat.com/archives/freeipa-devel/2010-November/msg00348.html > > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00906.html > > > > The only intersting thing I know, it's this doc to create FreeIPA server > > without Dogtag : > > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/creating-server.html > > > > Thanks you in advance for any information on the subject. > > > > -- > > Jean Eymerit > > > > > > -- > > 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 From sconley at caci.com Mon Nov 2 01:29:48 2015 From: sconley at caci.com (Sean Conley - US) Date: Mon, 2 Nov 2015 01:29:48 +0000 Subject: [Freeipa-users] how to chain CA certs Message-ID: Hello, I am new to FreeIPA and am attempting to stand up my first operational instance. We do have a commercial wildcard certificate (*.internal.example.org) that should cover the IPA server itself (ipa.internal.example.org). I used the -external-CA option when running the setup and so a CSR was generated. Since we have a wildcard cert, I wasn't sure if I really need to submit the CSR to our PKI vendor. At the same time, it's not clear to me through searching documents how I would extend the CA chain. Do I need to submit that CSR or is there a way for me to do this on my own? Any assistance is much appreciated. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Nov 2 05:40:59 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 2 Nov 2015 15:40:59 +1000 Subject: [Freeipa-users] how to chain CA certs In-Reply-To: References: Message-ID: <20151102054059.GL20018@dhcp-40-8.bne.redhat.com> On Mon, Nov 02, 2015 at 01:29:48AM +0000, Sean Conley - US wrote: > Hello, > > I am new to FreeIPA and am attempting to stand up my first > operational instance. We do have a commercial wildcard > certificate (*.internal.example.org) that should cover the IPA > server itself (ipa.internal.example.org). I used the -external-CA > option when running the setup and so a CSR was generated. Since > we have a wildcard cert, I wasn't sure if I really need to submit > the CSR to our PKI vendor. At the same time, it's not clear to me > through searching documents how I would extend the CA chain. Do I > need to submit that CSR or is there a way for me to do this on my > own? > Welcome to FreeIPA :) If you have a relationship with a Certificate Authority willing to sign an intermediate CA certificate for you, then you can use the --external-ca option, submit the generate CSR to your CA and once you receive your signed CA certificate, continue ipa-server-install. For a publicly-trusted intermediate CA cert, you are probably looking at $10,000s or $100,000s in fees, infrastructure and compliance costs to achieve this. Public CAs much prefer to keep you coming back to them for publicly trusted certificates :) If you already have some internal CA for your organisation, you can use it to sign the CSR. Otherwise, you can install FreeIPA with its own root CA (this is the default). HTH, Fraser > Any assistance is much appreciated. > > Sean > > -- > 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 From yks0000 at gmail.com Mon Nov 2 06:42:20 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 2 Nov 2015 12:12:20 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: <56337215.6000808@redhat.com> Message-ID: Adding to this, I am able to do ldsearch from the server which I am trying to make replica. [root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap:// ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: cn=changelog namingContexts: dc=klikpay,dc=int namingContexts: o=ipaca # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa-inf-prd-ng2-02 ~]# *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Mon, Nov 2, 2015 at 11:24 AM, Yogesh Sharma wrote: > Tried to re-enroll the replica however, getting the same error, though I > am able to connect to server. > > ===== > > Starting replication, please wait until this has completed. > > [ipa-inf-prd-ng2-01.klikpay.int] reports: Update failed! Status: [-1 - > LDAP error: Can't contact LDAP server] > > [error] RuntimeError: Failed to start replication > > ===== > > > [root at ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int 389 > Trying 172.16.32.10... > Connected to ipa-inf-prd-ng2-01.klikpay.int. > Escape character is '^]'. > ^] > telnet> quit > Connection closed. > [root at ipa-inf-prd-ng2-02 ~]# > > > > *Best Regards,* > > *__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > > On Fri, Oct 30, 2015 at 7:05 PM, Rob Crittenden > wrote: > >> Yogesh Sharma wrote: >> > Team, >> > >> > Noticed that user created on IPA Master are not replicating on Replica. >> > >> > Also, we create a new Zone in Master, However we do not see the same in >> > replica server. >> >> You need to figure out why ipa-inf-prd-ng2-01.klikpay.int can't contact >> port 389 on ipa-inf-prd-ng2-02.klikpay.int. It may be someone threw up a >> firewall without telling you, or someone tweaked the rules on either of >> those boxes. >> >> Doing re-init, force-sync, etc is always going to fail if one can't talk >> to the other. >> >> rob >> >> > >> > >> > Below is the information: >> > >> > From Master: >> > >> > [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v >> > ipa-inf-prd-ng2-01.klikpay.int >> > Directory Manager password: >> > >> > ipa-inf-prd-ng2-02.klikpay.int : >> > replica >> > last init status: None >> > last init ended: None >> > last update status: -1 Unable to acquire replicaLDAP error: Can't >> > contact LDAP server >> > last update ended: None >> > [root at ipa-inf-prd-ng2-01 ~]# >> > >> > >> > >> > From Replica: >> > >> > >> > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v >> > ipa-inf-prd-ng2-02.klikpay.int >> > Directory Manager password: >> > >> > ipa-inf-prd-ng2-01.klikpay.int : >> > replica >> > last init status: None >> > last init ended: None >> > last update status: 0 Replica acquired successfully: Incremental >> > update succeeded >> > last update ended: 2015-10-30 10:36:25+00:00 >> > [root at ipa-inf-prd-ng2-02 ~]# >> > >> > >> > Though it says it is replicated (last update ended), We are not seeing >> > new users and the new DNS Zone which we created >> > >> > >> > I also tried force replication, though I can not see the new Changes: >> > >> > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from >> > ipa-inf-prd-ng2-01.klikpay.int >> > Directory Manager password: >> > >> > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int >> > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping >> > tree,cn=config schedule to 2358-2359 0 to force synch >> > ipa: INFO: Deleting schedule 2358-2359 0 from agreement >> > cn=meToipa-inf-prd-ng2-02.klikpay.int >> > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping >> > tree,cn=config >> > [root at ipa-inf-prd-ng2-02 ~]# >> > >> > >> > Once I do re-initialization, it gives "Can't Contact LDAP Server" >> > >> > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize --from >> > ipa-inf-prd-ng2-01.klikpay.int >> > Directory Manager password: >> > >> > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int >> > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping >> > tree,cn=config schedule to 2358-2359 0 to force synch >> > ipa: INFO: Deleting schedule 2358-2359 0 from agreement >> > cn=meToipa-inf-prd-ng2-02.klikpay.int >> > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping >> > tree,cn=config >> > >> > [ipa-inf-prd-ng2-01.klikpay.int > >] >> > reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP >> > server] >> > >> > >> > >> > >> > /Best Regards,/ >> > /__________________________________________ >> > / >> > /Yogesh Sharma >> > / >> > /Email: yks0000 at gmail.com | Web: >> www.initd.in >> > / >> > / >> > / >> > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ >> > >> > < >> https://twitter.com/checkwithyogesh> < >> http://google.com/+YogeshSharmaOnGooglePlus> >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Nov 2 06:53:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Nov 2015 08:53:04 +0200 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: <56337215.6000808@redhat.com> Message-ID: <20151102065304.GB8374@redhat.com> On Mon, 02 Nov 2015, Yogesh Sharma wrote: >Adding to this, I am able to do ldsearch from the server which I am trying >to make replica. > >[root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap:// >ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts ># extended LDIF ># ># LDAPv3 ># base <> with scope baseObject ># filter: (objectclass=*) ># requesting: namingContexts ># What about port 636? Replica install requires LDAPS. -- / Alexander Bokovoy From yks0000 at gmail.com Mon Nov 2 07:01:58 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 2 Nov 2015 12:31:58 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: <20151102065304.GB8374@redhat.com> References: <56337215.6000808@redhat.com> <20151102065304.GB8374@redhat.com> Message-ID: Listening: [root at ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int 636 Trying 172.16.32.10... Connected to ipa-inf-prd-ng2-01.klikpay.int. Escape character is '^]'. *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Mon, Nov 2, 2015 at 12:23 PM, Alexander Bokovoy wrote: > On Mon, 02 Nov 2015, Yogesh Sharma wrote: > >> Adding to this, I am able to do ldsearch from the server which I am trying >> to make replica. >> >> [root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap:// >> ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts >> # extended LDIF >> # >> # LDAPv3 >> # base <> with scope baseObject >> # filter: (objectclass=*) >> # requesting: namingContexts >> # >> > What about port 636? Replica install requires LDAPS. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Mon Nov 2 05:54:58 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 2 Nov 2015 11:24:58 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: <56337215.6000808@redhat.com> References: <56337215.6000808@redhat.com> Message-ID: Tried to re-enroll the replica however, getting the same error, though I am able to connect to server. ===== Starting replication, please wait until this has completed. [ipa-inf-prd-ng2-01.klikpay.int] reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP server] [error] RuntimeError: Failed to start replication ===== [root at ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int 389 Trying 172.16.32.10... Connected to ipa-inf-prd-ng2-01.klikpay.int. Escape character is '^]'. ^] telnet> quit Connection closed. [root at ipa-inf-prd-ng2-02 ~]# *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Fri, Oct 30, 2015 at 7:05 PM, Rob Crittenden wrote: > Yogesh Sharma wrote: > > Team, > > > > Noticed that user created on IPA Master are not replicating on Replica. > > > > Also, we create a new Zone in Master, However we do not see the same in > > replica server. > > You need to figure out why ipa-inf-prd-ng2-01.klikpay.int can't contact > port 389 on ipa-inf-prd-ng2-02.klikpay.int. It may be someone threw up a > firewall without telling you, or someone tweaked the rules on either of > those boxes. > > Doing re-init, force-sync, etc is always going to fail if one can't talk > to the other. > > rob > > > > > > > Below is the information: > > > > From Master: > > > > [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v > > ipa-inf-prd-ng2-01.klikpay.int > > Directory Manager password: > > > > ipa-inf-prd-ng2-02.klikpay.int : > > replica > > last init status: None > > last init ended: None > > last update status: -1 Unable to acquire replicaLDAP error: Can't > > contact LDAP server > > last update ended: None > > [root at ipa-inf-prd-ng2-01 ~]# > > > > > > > > From Replica: > > > > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v > > ipa-inf-prd-ng2-02.klikpay.int > > Directory Manager password: > > > > ipa-inf-prd-ng2-01.klikpay.int : > > replica > > last init status: None > > last init ended: None > > last update status: 0 Replica acquired successfully: Incremental > > update succeeded > > last update ended: 2015-10-30 10:36:25+00:00 > > [root at ipa-inf-prd-ng2-02 ~]# > > > > > > Though it says it is replicated (last update ended), We are not seeing > > new users and the new DNS Zone which we created > > > > > > I also tried force replication, though I can not see the new Changes: > > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from > > ipa-inf-prd-ng2-01.klikpay.int > > Directory Manager password: > > > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > > tree,cn=config schedule to 2358-2359 0 to force synch > > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > > cn=meToipa-inf-prd-ng2-02.klikpay.int > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > > tree,cn=config > > [root at ipa-inf-prd-ng2-02 ~]# > > > > > > Once I do re-initialization, it gives "Can't Contact LDAP Server" > > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize --from > > ipa-inf-prd-ng2-01.klikpay.int > > Directory Manager password: > > > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > > tree,cn=config schedule to 2358-2359 0 to force synch > > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > > cn=meToipa-inf-prd-ng2-02.klikpay.int > > >,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > > tree,cn=config > > > > [ipa-inf-prd-ng2-01.klikpay.int ] > > reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP > > server] > > > > > > > > > > /Best Regards,/ > > /__________________________________________ > > / > > /Yogesh Sharma > > / > > /Email: yks0000 at gmail.com | Web: www.initd.in > > / > > / > > / > > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ > > > > < > https://twitter.com/checkwithyogesh> < > http://google.com/+YogeshSharmaOnGooglePlus> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Nov 2 12:30:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 13:30:45 +0100 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: <56337215.6000808@redhat.com> <20151102065304.GB8374@redhat.com> Message-ID: <56375775.3030408@redhat.com> On 02.11.2015 08:01, Yogesh Sharma wrote: > Listening: > > [root at ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int > 636 > Trying 172.16.32.10... > Connected to ipa-inf-prd-ng2-01.klikpay.int > . > Escape character is '^]'. Can you try also ldaps with ldapsearch? > > /Best Regards,/ > /__________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: > www.initd.in / > / > / > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ > > > > > > On Mon, Nov 2, 2015 at 12:23 PM, Alexander Bokovoy > > wrote: > > On Mon, 02 Nov 2015, Yogesh Sharma wrote: > > Adding to this, I am able to do ldsearch from the server which > I am trying > to make replica. > > [root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap:// > ipa-inf-prd-ng2-01.klikpay.int > -s base -b '' > namingContexts > # extended LDIF > # > # LDAPv3 > # base <> with scope baseObject > # filter: (objectclass=*) > # requesting: namingContexts > # > > What about port 636? Replica install requires LDAPS. > > -- > / Alexander Bokovoy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitra.dehghan at gmail.com Mon Nov 2 12:21:45 2015 From: mitra.dehghan at gmail.com (mitra dehghan) Date: Mon, 2 Nov 2015 15:51:45 +0330 Subject: [Freeipa-users] Sync IPA and AD while using external CA In-Reply-To: References: <5630D2B6.7080506@redhat.com> <563374FB.7030302@redhat.com> Message-ID: Hello, This is the approach I have followed till now: I edited /etc/openldap/ldap.conf as follow: TLS_REQCERT allow after restarting of dirsrv and using Active directoy's CA file in --cacert switch it procceded making Sync agreement but failed to do update with this error: NSMMReplicationPlugin - agmt="cn=meToad-sercer.local.dc" (ad-server:389) : Replication bind with SIMPLE auth failed: LDAP error -11 (connect error) (TLS error -8174:security library: bad database.) slapi_ldap_bind - Error: could not send startTLS request: error -11 (connect error) errno 0 (Success) I would be glad if anyone could help me to resolve the error. On Sat, Oct 31, 2015 at 11:37 AM, mitra dehghan wrote: > Dear Rob, > Thanks for your response: > > > > Yes but which cert did you provider, the root CA contoso.com or the > subordinate CA local.dc? > Actually I was using active directory's certificate with --cacert switch > in ipa-replica-manage > Thanks to info you gave me about NSS I changed the approach. > first: using certutil, I manually added root CA (contoso.com) and > subordinate(local.dc) certificates in /etc/dirsrv/slapd-REALM database > # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "contoso.com CA" -t CT,, > -a -i /path/to/contoso.pem > # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "local.dc CA" -t CT,, -a > -i /path/to/localdc.pem > > then, following same approach, I added Active directory's certificate to > the same db. > # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "active directory CA" -t > ,, -a -i /path/to/ad.cer > Note: since the original certificates were in .cer format and its same as > .pem I just renamed certificates to .pem > > Now my db has 5 certificates in: > a) root CA certificate (contoso.com) > b) Subordinate CA (local.dc): issued to local.dc by contoso.com > c) Active directory CA (ad): issued to active directory by local.dc > d)IPA certificate:issued to IPA server by local.dc > e)localhost certificate: issued to localhost by IPA server 's internal CA. > > finally I ran ipa-replica-manage: > - using contoso.com CA in --cacert it says TLS error -8179: Peer's > Certificate issuer is not recognized > -using local.dc CA in --cacert it says TLS error -8157: Certificate > extension not found. > -using Active Directory CA in --cacert it says TLS error -8179: Peer's > Certificate issuer is not recognized > > I would be glad if you help me more with this issue! > > On Fri, Oct 30, 2015 at 5:17 PM, Rob Crittenden > wrote: > >> Please keep responses on the list >> >> mitra dehghan wrote: >> > Thank you for your response. >> > -First of all in section 15.5.1 of Red hat Enterprise Linux 6 Identity >> > Management guide it says to copy both ad and IPA certificates in >> > /etc/openldap/certs and i did the same. of course it worked when i was >> > using internal CAs. >> >> Ok, it doesn't hurt anything, but for the purposes of ipa-replica-manage >> it is a no-op. >> >> >> > - I pass ad certificate in ipa-replica-manage command via --cacert >> switch. >> >> Yes but which cert did you provider, the root CA contoso.com or the >> subordinate CA local.dc? >> >> > - After all I would be glad if you could give me more info about NSS >> > database. Is that kind of substitute for /etc/openldap/certs? would you >> > please give me more details about configurations needed for that? >> >> The crypto library that 389-ds uses is NSS. This uses a database to >> store certificates and keys rather than discrete files. The certutil >> tool is used to manage this file (there is a brief man page). >> >> ipa-replica-manage will add the AD cert to 389-ds for you, but you can >> add certs manually and I think it might help in this case: >> >> # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "contoso.com CA" -t >> CT,, -a -i /path/to/contoso.pem >> # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "local.dc CA" -t CT,, >> -a -i /path/to/localdc.pem >> >> The -n option specifies a "nickname" to use for the certificate. You can >> use pretty much anything you want but being descriptive helps. >> >> rob >> >> > >> > >> > >> > On Wed, Oct 28, 2015 at 5:20 PM, Rob Crittenden > > > wrote: >> > >> > mitra dehghan wrote: >> > > hello, >> > > I want to implement and IPA server and Sync it with my 2012 ms ad. >> > While >> > > things go well using an internal CA in each server, I came across >> kind >> > > of problem when I want integrate solution with my PKI which is >> already >> > > serving the AD server. >> > > I can install IPA with --external-ca switch. but when it comes to >> > Sync. >> > > agreement it says "TLS error -8179:Peer's Certificate issuer is >> not >> > > recognized." >> > > >> > > The architecture is: >> > > - There is a root CA named contoso.com >> > >> > > - There is a subordinate CA named local.dc >> > > - The certificates of AD and IPA server are both issued by >> local.dc >> > > - IPA's certificate is issued based on the CSR file generated by >> > > ipa-server-install >> > > - I have copied both certificates in /etc/openldap/certs >> directory and >> > > the rest was same as what i did in the internal CA scenario. >> > > >> > > while the FreeIPA docs say both servers must have internal CA's i >> need >> > > to integrate solution with available PKI. >> > > I would be glad hear suggestions if this scenario is applicable >> > and what >> > > is wrong there. >> > > thank you >> > >> > 389-ds doesn't use /etc/openldap/certs. >> > >> > What cert are you passing in when creating the winsync agreement >> using >> > ipa-replica-manage? >> > >> > You may need/want to add these certs to the IPA 389-ds NSS database >> > prior to setting up the agreement. >> > >> > rob >> > >> > >> > >> > >> > -- >> > m-dehghan >> >> > > > -- > m-dehghan > -- m-dehghan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Nov 2 16:33:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 2 Nov 2015 17:33:15 +0100 Subject: [Freeipa-users] What is the recommended procedure for upgrading clients and servers to F23? In-Reply-To: References: Message-ID: <5637904B.1010309@redhat.com> On 10/31/2015 06:54 PM, Fujisan wrote: > Hi there, > > F23 is coming out very soon and I'm wondering what machine I should upgrade > first, the spa clients or the ipa servers? It should not matter, for normal FreeIPA function. Older clients will not be able to use new FreeIPA server features, but the old ones should work. > In other words, can the ipa system work with ipa client upgraded to 4.2 and > the servers still at 4.1.4? Yes. Except that "ipa" command itself will not work as it cannot work older server. You would need to use "ipa" command from the FreeIPA server itself or some other machine with the same or lower version. > Or do I have to upgrade the servers first? > > And should I upgrade to freeipa 4.2 first and then upgrade the machines to > F23? More info here: http://www.freeipa.org/page/Client#Compatibility Before you start upgrading FreeIPA servers to Fedora 23, please wait until https://bugzilla.redhat.com/show_bug.cgi?id=1274905 is fixed. We would like to release a new FreeIPA version today or tomorrow and do the Fedora 23 0day update with the fix. We are sorry for the inconvenience. From mkosek at redhat.com Mon Nov 2 16:48:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 2 Nov 2015 17:48:25 +0100 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 Message-ID: <563793D9.8050508@redhat.com> Hello everyone, Fedora 23 with the new and shiny FreeIPA 4.2 will be out tomorrow. The release adds a lot of new exiting functionality and we are eager to hear your thoughts on the release [1]. Unfortunately, the FreeIPA upgrade on Fedora 23 is broken at the moment and fails on updating the LDAP schema. The problem is tracked in Red Hat Bugzilla [2]. The problem is fixed in upstream project, the development team is now working on releasing FreeIPA upstream release 4.2.3 ASAP and also publishing it as a 0-day update for Fedora 23. This situation should be resolved within couple days, when the released build hits the official Fedora repos and mirrors. Until the fixed FreeIPA version is released and in the Fedora repos, please wait with updating your existing FreeIPA installation. We will keep you posted. We are very sorry for the inconvenience. [1] http://www.freeipa.org/page/Releases/4.2.0 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1274905 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Mon Nov 2 21:01:11 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 22:01:11 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.2.3 Message-ID: <5637CF17.8010700@redhat.com> The FreeIPA team would like to announce FreeIPA v4.2.3 bug fixing release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 23 and rawhide. Builds for Fedora 22 are available in the official COPR repository . Fedora update: and related pki-core update: == Highlights in 4.2.3 == FreeIPA 4.2.3 is a bugfix release to improve upgrade experience from FreeIPA 4.1 for Fedora 23 where Tomcat 8 was introduced. === Bug fixes === * fixed upgrade failures #5359, #5360 and * fixed regression in automember Web UI - disappearing expression === Enhancements === * new French and German translations * improved validation of Realm Domains, * ipa-adtrust-install prints complete SRV records so that they are suitable for copy&pasting to zone files == Upgrading == Upgrade instructions are available on upgrade page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.2.2 == === David Kupka (1) === * comment: Add Documentation string to deduplicate function === Gabe Alford (2) === * Remove bind configuration detected question * Warn if no installation found when running ipa-server-install --uninstall === Jan Cholasta (3) === * schema: do not derive ipaVaultPublicKey from ipaPublicKey * upgrade: make sure ldap2 is connected in export_kra_agent_pem * vault: fix private service vault creation === Martin Babinsky (4) === * remove ID overrides when deleting a user * execute user-del pre-callback also during user preservation * fix class teardown in user plugin tests * always ask the resolver for the reverse zone when manipulating PTR records === Martin Ba?ti (7) === * CI TEST: Vault * CI Test: add setup_kra options into install scripts * Replace tab with space in test_user_plugin.py * DNSSEC CI: wait until DS records is replicated * DNSSEC: Remove service containers from LDAP after uninstalling * DNSSEC: warn user if DNSSEC key master is not installed * KRA: fix check that CA is installed === Milan Kub?k (6) === * ipatests: add fuzzy instances for CA ACL DN and RDN * ipatests: Add initial CAACLTracker implementation * tests: add test to check the default ACL * ipatests: CA ACL - added config templates * ipatests: added unlock_principal_password and change_principal * ipatests: CA ACL and cert profile functional test === Oleg Fayans (1) === * Fixed a timing issue with drill returning non-zero exitcode === Petr Voborn?k (2) === * Update .po files * Become IPA 4.2.3 === Petr ?pa?ek (1) === * ipa-adtrust-install: Print complete SRV records === Stanislav Laznicka (1) === * Fixes disappearing automember expressions === Tom?? Babej (10) === * util: Add detect_dns_zone_realm_type helper * realmdomains: Minor style and wording improvements * realmdomains: Add validation that realmdomain being added is indeed from our realm * realmdomains: Issue a warning when automated management of realmdomains failed * realmdomains: Do not fail due the ValidationError when adding _kerberos TXT record * tests: Amend result assertions in realmdomains tests * idoverride: Ignore ValidationErrors when converting the anchor * tests: Add tests for idoverride object integrity * trusts: Make trust_show.get_dn raise properly formatted NotFound * trustdomain: Perform validation of the trust domain first -- Petr Vobornik From andrew.krause at breakthroughfuel.com Mon Nov 2 23:05:59 2015 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Mon, 2 Nov 2015 23:05:59 +0000 Subject: [Freeipa-users] Duplicate objects after 4.1 ipa-server upgrade Message-ID: <998EC6EB-A08E-4F0A-A154-A6A924D7553F@breakthroughfuel.com> After upgrading to 4.1 I have duplicated permission objects in my directory with names including nsuniqueid. Is it safe to delete all of these objects? Somehow this is only causing an issue for a specific user hitting a specific HBAC policy. (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ????.. (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules This is causing authentication to fail for the user in question, and I would like to get rid of these useless objects if they are no longer necessary. From colton at sparksis.com Tue Nov 3 05:23:00 2015 From: colton at sparksis.com (Colton) Date: Mon, 2 Nov 2015 22:23:00 -0700 Subject: [Freeipa-users] application specific passwords Message-ID: Hi All, I'm looking for further information on https://fedorahosted.org/freeipa/ticket/4510 applicaiton specific passwords. Has anyone had luck setting up OTP alongside app specific passwords in FreeIPA directly. Unfortunately, without having even rudimentary gui tools for the end user I can't see OTP being useful. Many mail applications simply authenticate via password each session and this would break those applications. Even worse basic http authentication won't last the length of a session and will expire after the auth window has elapsed for a given password. The use case that I'm most frustrated with is my owncloud sync clients. Owncloud on the desktop seems to setup an adequate user session such that I haven't had to reauthenticate the client. The webdav viewer and the mobile apps on the other hand both cause the user to immediately logout if they use their otp to login (and potentially locks the user account based on too many failed password attempts). Any help on setting up OTP with app specific passwords on would be greatly appreciated. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 3 07:42:37 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 3 Nov 2015 08:42:37 +0100 Subject: [Freeipa-users] Duplicate objects after 4.1 ipa-server upgrade In-Reply-To: <998EC6EB-A08E-4F0A-A154-A6A924D7553F@breakthroughfuel.com> References: <998EC6EB-A08E-4F0A-A154-A6A924D7553F@breakthroughfuel.com> Message-ID: <5638656D.4020109@redhat.com> On 11/03/2015 12:05 AM, Andrew Krause wrote: > After upgrading to 4.1 I have duplicated permission objects in my directory with names including nsuniqueid. Is it safe to delete all of these objects? Somehow this is only causing an issue for a specific user hitting a specific HBAC policy. > > (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ????.. > (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request > (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules > > > This is causing authentication to fail for the user in question, and I would like to get rid of these useless objects if they are no longer necessary. It looks like you had some replication problem in your network, or maybe upgraded 2 FreeIPA instances at the same time, so they both generated conflicting permissions? In any case, it should be case to delete the permissions with nsuniqueid, FreeIPA should generate the managed permissions from scratch anyway, if they are missing and upgrade is run again. More info on replication conflicts here: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts Martin From mkosek at redhat.com Tue Nov 3 07:44:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 3 Nov 2015 08:44:19 +0100 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: <563793D9.8050508@redhat.com> References: <563793D9.8050508@redhat.com> Message-ID: <563865D3.5030305@redhat.com> On 11/02/2015 05:48 PM, Martin Kosek wrote: > Hello everyone, > > Fedora 23 with the new and shiny FreeIPA 4.2 will be out tomorrow. The release > adds a lot of new exiting functionality and we are eager to hear your thoughts > on the release [1]. > > Unfortunately, the FreeIPA upgrade on Fedora 23 is broken at the moment and > fails on updating the LDAP schema. The problem is tracked in Red Hat Bugzilla > [2]. The problem is fixed in upstream project, the development team is now > working on releasing FreeIPA upstream release 4.2.3 ASAP and also publishing it > as a 0-day update for Fedora 23. This situation should be resolved within > couple days, when the released build hits the official Fedora repos and mirrors. > > Until the fixed FreeIPA version is released and in the Fedora repos, please > wait with updating your existing FreeIPA installation. > > We will keep you posted. We are very sorry for the inconvenience. > > [1] http://www.freeipa.org/page/Releases/4.2.0 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1274905 > The respective F23 updates are now heading to testing repo: FreeIPA: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e pki-core: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f12c332a2f Martin From pspacek at redhat.com Tue Nov 3 11:05:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 Nov 2015 12:05:09 +0100 Subject: [Freeipa-users] [Freeipa-devel] Open ports for client can auth over wan In-Reply-To: References: <56387667.5070700@redhat.com> Message-ID: <563894E5.3020101@redhat.com> Hello, please do not drop freeipa-users list when replying. There is plenty of smart people who can reply instead of me :-) Anyway: On 3.11.2015 10:31, Martin J?rgensen wrote: > Okay all of them, also bind is that not a vulnerability? If you are asking about DNS server BIND, then you need to do hardening steps as usual for publicly-available DNS server. There are other things to consider, please read following thread: https://www.redhat.com/archives/freeipa-users/2014-April/msg00243.html Let us know if you have further questions. Petr^2 Spacek > 2015-11-03 9:55 GMT+01:00 Petr Spacek : > >> On 3.11.2015 09:42, Martin J?rgensen wrote: >>> Hi >>> >>> Loves freeipa, using it on all of my machines, i have som vm in the >> cloud, >>> which port do i have to open out for these client can auth? >> >> ipa-server-install prints list of ports you need to open. For full >> functionality you need to open all of them. >> >> -- >> Petr^2 Spacek From th at casalogic.dk Tue Nov 3 12:09:53 2015 From: th at casalogic.dk (Troels Hansen) Date: Tue, 3 Nov 2015 13:09:53 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151030141953.GU8374@redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> Message-ID: <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> Hi again, so I finally got time to look further into this. This task works: dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config add:objectclass:top,extensibleObject add:cn:$TIME-$FQDN-$LIBARCH add:nsslapd-basedn:"$SUFFIX" add:delay:0 add:ttl:3600 However, the task gets generated, but no output can be pulled from the task: ldapsearch -D "cn=Directory Manager" -W -b 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config objectClass: top objectClass: extensibleObject nsslapd-basedn: dc=casalogic,dc=lan delay: 0 cn: 1446551851-kenai.casalogic.lan-64 ttl: 3600 nstaskcurrentitem: 1 nstasktotalitems: 1 nstaskexitcode: 32 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: Only a exitcode 32 The nstaskcurrentitem and nstasktotalitems remains the same till the task disappeares. Any way do debug these taske further to find out which user it stops at, as it looks like it detects an error at one user and stops the task? ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: > On Fri, 30 Oct 2015, Troels Hansen wrote: >> >> >> >>> I think it should be >>> add:nsslapd-basedn: cn=accounts,$SUFFIX >>> not >>> add:basedn:"cn=accounts,$SUFFIX" >>> >>> this is what sidgen task expects and it returns constraint violation >>> error if parameters are wrong: >>> >>> str = fetch_attr(e, "nsslapd-basedn", NULL); >>> if (str == NULL) { >>> LOG_FATAL("Missing nsslapd-basedn!\n"); >>> *returncode = LDAP_CONSTRAINT_VIOLATION; >>> ret = SLAPI_DSE_CALLBACK_ERROR; >>> goto done; >>> } >>> >> >>I think you are right. >>Don't know what I have tested, but it brings me a different error, that I didn't >>see before: >> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: >>{'desc': 'Operations error'} >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations >>error: >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The >>ipa-ldap-updater command was successful >> >>Where did you find the source for the sidgen task? I could try looking at at it >>myself, but can't find it. > You can check it here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 > > -- > / Alexander Bokovoy -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From sbose at redhat.com Tue Nov 3 12:36:04 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 3 Nov 2015 13:36:04 +0100 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> Message-ID: <20151103123604.GD22483@p.redhat.com> On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote: > Hi again, so I finally got time to look further into this. > > This task works: > > dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config > add:objectclass:top,extensibleObject > add:cn:$TIME-$FQDN-$LIBARCH > add:nsslapd-basedn:"$SUFFIX" > add:delay:0 > add:ttl:3600 > > However, the task gets generated, but no output can be pulled from the task: > > ldapsearch -D "cn=Directory Manager" -W -b 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config > dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config > objectClass: top > objectClass: extensibleObject > nsslapd-basedn: dc=casalogic,dc=lan > delay: 0 > cn: 1446551851-kenai.casalogic.lan-64 > ttl: 3600 > nstaskcurrentitem: 1 > nstasktotalitems: 1 > nstaskexitcode: 32 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: > > Only a exitcode 32 > The nstaskcurrentitem and nstasktotalitems remains the same till the task disappeares. > Any way do debug these taske further to find out which user it stops at, as it looks like it detects an error at one user and stops the task? You can activate 'Plug-in debugging' by setting the nsslapd-errorlog-level attribute of cn=config to 65536, see http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for details. Make sure to switch it back to 0 after running the sidgen task because the logging is quite expensive. HTH bye, Sumit > > ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: > > > On Fri, 30 Oct 2015, Troels Hansen wrote: > >> > >> > >> > >>> I think it should be > >>> add:nsslapd-basedn: cn=accounts,$SUFFIX > >>> not > >>> add:basedn:"cn=accounts,$SUFFIX" > >>> > >>> this is what sidgen task expects and it returns constraint violation > >>> error if parameters are wrong: > >>> > >>> str = fetch_attr(e, "nsslapd-basedn", NULL); > >>> if (str == NULL) { > >>> LOG_FATAL("Missing nsslapd-basedn!\n"); > >>> *returncode = LDAP_CONSTRAINT_VIOLATION; > >>> ret = SLAPI_DSE_CALLBACK_ERROR; > >>> goto done; > >>> } > >>> > >> > >>I think you are right. > >>Don't know what I have tested, but it brings me a different error, that I didn't > >>see before: > >> > >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: > >>{'desc': 'Operations error'} > >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations > >>error: > >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The > >>ipa-ldap-updater command was successful > >> > >>Where did you find the source for the sidgen task? I could try looking at at it > >>myself, but can't find it. > > You can check it here: > > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 > > > > -- > > / Alexander Bokovoy > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > > -- > 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 From yks0000 at gmail.com Tue Nov 3 13:48:20 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Tue, 3 Nov 2015 19:18:20 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: <56375775.3030408@redhat.com> References: <56337215.6000808@redhat.com> <20151102065304.GB8374@redhat.com> <56375775.3030408@redhat.com> Message-ID: LDAPS is also fine: [root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldaps:// ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: cn=changelog namingContexts: dc=klikpay,dc=int namingContexts: o=ipaca # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa-inf-prd-ng2-02 ~]# *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Mon, Nov 2, 2015 at 6:00 PM, Martin Basti wrote: > > > On 02.11.2015 08:01, Yogesh Sharma wrote: > > Listening: > > [root at ipa-inf-prd-ng2-02 ~]# telnet ipa-inf-prd-ng2-01.klikpay.int 636 > Trying 172.16.32.10... > Connected to ipa-inf-prd-ng2-01.klikpay.int. > Escape character is '^]'. > > > Can you try also ldaps with ldapsearch? > > > *Best Regards,* > > *__________________________________________ * > > *Yogesh Sharma * > *Email: yks0000 at gmail.com | Web: > www.initd.in * > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > > On Mon, Nov 2, 2015 at 12:23 PM, Alexander Bokovoy < > abokovoy at redhat.com> wrote: > >> On Mon, 02 Nov 2015, Yogesh Sharma wrote: >> >>> Adding to this, I am able to do ldsearch from the server which I am >>> trying >>> to make replica. >>> >>> [root at ipa-inf-prd-ng2-02 ~]# ldapsearch -x -H ldap:// >>> ipa-inf-prd-ng2-01.klikpay.int -s base -b '' namingContexts >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base <> with scope baseObject >>> # filter: (objectclass=*) >>> # requesting: namingContexts >>> # >>> >> What about port 636? Replica install requires LDAPS. >> >> -- >> / Alexander Bokovoy >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.krause at breakthroughfuel.com Tue Nov 3 15:24:31 2015 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Tue, 3 Nov 2015 15:24:31 +0000 Subject: [Freeipa-users] Duplicate objects after 4.1 ipa-server upgrade In-Reply-To: <5638656D.4020109@redhat.com> References: <998EC6EB-A08E-4F0A-A154-A6A924D7553F@breakthroughfuel.com> <5638656D.4020109@redhat.com> Message-ID: <54FEAB83-D6B7-44AD-8288-7E4F1FEC67CF@breakthroughfuel.com> I upgraded 4 at the same time actually. It makes sense why the objects were created and I do understand how replication conflicts are handled. I just wanted to be absolutely certain that it was ok to delete these objects since it seems pointless to ever keep them around. Has there been any talk of a mechanism to just handle this on a regular basis (not that this situation should happen regularly)? > On Nov 3, 2015, at 1:42 AM, Martin Kosek wrote: > > On 11/03/2015 12:05 AM, Andrew Krause wrote: >> After upgrading to 4.1 I have duplicated permission objects in my directory with names including nsuniqueid. Is it safe to delete all of these objects? Somehow this is only causing an issue for a specific user hitting a specific HBAC policy. >> >> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ????.. >> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request >> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules >> >> >> This is causing authentication to fail for the user in question, and I would like to get rid of these useless objects if they are no longer necessary. > > It looks like you had some replication problem in your network, or maybe > upgraded 2 FreeIPA instances at the same time, so they both generated > conflicting permissions? > > In any case, it should be case to delete the permissions with nsuniqueid, > FreeIPA should generate the managed permissions from scratch anyway, if they > are missing and upgrade is run again. > > More info on replication conflicts here: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts > > Martin From lkrispen at redhat.com Tue Nov 3 15:49:00 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 03 Nov 2015 16:49:00 +0100 Subject: [Freeipa-users] Duplicate objects after 4.1 ipa-server upgrade In-Reply-To: <54FEAB83-D6B7-44AD-8288-7E4F1FEC67CF@breakthroughfuel.com> References: <998EC6EB-A08E-4F0A-A154-A6A924D7553F@breakthroughfuel.com> <5638656D.4020109@redhat.com> <54FEAB83-D6B7-44AD-8288-7E4F1FEC67CF@breakthroughfuel.com> Message-ID: <5638D76C.402@redhat.com> On 11/03/2015 04:24 PM, Andrew Krause wrote: > I upgraded 4 at the same time actually. It makes sense why the objects were created and I do understand how replication conflicts are handled. I just wanted to be absolutely certain that it was ok to delete these objects since it seems pointless to ever keep them around. Has there been any talk of a mechanism to just handle this on a regular basis (not that this situation should happen regularly)? there are requests to hide these conflict entries so that the do not interfere with other operations and there is ongoing discussion in DS to implement another mechanism which doesn't have these side effects. But on the other hand these entries are not generated out of the blue, they indicate a scenario on the application/client side where the same entry is added simultaneously on two or more servers. maybe as Martin said by upgrading in parallel or by impatient clients which move to another servers if no immediat success or by misconfigured proxies or load balancers which send ops to multiple masters. So these conflict entries could also seen as a hint that somthing is or was wrong. You can proactively check for these entries before and harm is done and delete them. Do ldapsearch -b "" "nsds5ReplConflict=*" nsds5ReplConflict > > >> On Nov 3, 2015, at 1:42 AM, Martin Kosek wrote: >> >> On 11/03/2015 12:05 AM, Andrew Krause wrote: >>> After upgrading to 4.1 I have duplicated permission objects in my directory with names including nsuniqueid. Is it safe to delete all of these objects? Somehow this is only causing an issue for a specific user hitting a specific HBAC policy. >>> >>> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Read PassSync Managers Configuration+nsuniqueid=4ae3220f-4d2b11e5-a06ffcc2-215714a9 ????.. >>> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request >>> (Mon Nov 2 14:29:23 2015) [sssd[be[blue-shift.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules >>> >>> >>> This is causing authentication to fail for the user in question, and I would like to get rid of these useless objects if they are no longer necessary. >> It looks like you had some replication problem in your network, or maybe >> upgraded 2 FreeIPA instances at the same time, so they both generated >> conflicting permissions? >> >> In any case, it should be case to delete the permissions with nsuniqueid, >> FreeIPA should generate the managed permissions from scratch anyway, if they >> are missing and upgrade is run again. >> >> More info on replication conflicts here: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#Solving_Common_Replication_Conflicts-Solving_Naming_Conflicts >> >> Martin > From sconley at caci.com Tue Nov 3 17:30:03 2015 From: sconley at caci.com (Sean Conley - US) Date: Tue, 3 Nov 2015 17:30:03 +0000 Subject: [Freeipa-users] how to chain CA certs In-Reply-To: <20151102054059.GL20018@dhcp-40-8.bne.redhat.com> References: <20151102054059.GL20018@dhcp-40-8.bne.redhat.com> Message-ID: Not sure if I should start a new thread for this, but... I am now trying to follow the instructions given in this thread: https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html. I think this configuration should work well with our deployment strategy. I feel like I am following the steps exactly but always end up with "full certificate chain is not present in /etc/ipa/pki/example.org.p12? during ipa-server-install. Have others followed this process more recently? I am wondering if there might have been any changes so that these steps no longer work, or possibly there is an easier way to do this now. I am running version: ipa-server-4.1.0-18.el7.centos.4.x86_64. On 11/1/15, 10:40 PM, "Fraser Tweedale" wrote: >On Mon, Nov 02, 2015 at 01:29:48AM +0000, Sean Conley - US wrote: >> Hello, >> >> I am new to FreeIPA and am attempting to stand up my first >> operational instance. We do have a commercial wildcard >> certificate (*.internal.example.org) that should cover the IPA >> server itself (ipa.internal.example.org). I used the -external-CA >> option when running the setup and so a CSR was generated. Since >> we have a wildcard cert, I wasn't sure if I really need to submit >> the CSR to our PKI vendor. At the same time, it's not clear to me >> through searching documents how I would extend the CA chain. Do I >> need to submit that CSR or is there a way for me to do this on my >> own? >> >Welcome to FreeIPA :) > >If you have a relationship with a Certificate Authority willing to >sign an intermediate CA certificate for you, then you can use the >--external-ca option, submit the generate CSR to your CA and once >you receive your signed CA certificate, continue ipa-server-install. > >For a publicly-trusted intermediate CA cert, you are probably >looking at $10,000s or $100,000s in fees, infrastructure and >compliance costs to achieve this. Public CAs much prefer to keep >you coming back to them for publicly trusted certificates :) > >If you already have some internal CA for your organisation, you can >use it to sign the CSR. > >Otherwise, you can install FreeIPA with its own root CA (this is the >default). > >HTH, >Fraser > >> Any assistance is much appreciated. >> >> Sean >> > >> -- >> 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 > From sconley at caci.com Tue Nov 3 18:00:52 2015 From: sconley at caci.com (Sean Conley - US) Date: Tue, 3 Nov 2015 18:00:52 +0000 Subject: [Freeipa-users] using wildcard cert from external CA Message-ID: Sorry for the redundancy but I thought it would be better to start a new thread since I am really asking a different question at this point. We are trying to stand up an IPA instance using real certs (wildcard) for our domain, so that external users get a valid cert when coming the the https UI. I am trying to follow the steps given in this thread: https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html. It seems no matter what I do, I end up with: "full certificate chain is not present in /etc/ipa/pki/example.org.p12". Has this process been documented more completely anywhere? Is this still a valid process? I know that there is now an -external-ca option to ipa-server-install, but I have questions about the CSR process from my CA and they are not being very responsive. I have also been told that this option would require a reseller arrangement potentially costing a lot of money... we don't want to be in the CA business... we just want our external users to be able to securely access IPA. Thanks again in advance for any assistance. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 3 19:05:56 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Nov 2015 14:05:56 -0500 Subject: [Freeipa-users] using wildcard cert from external CA In-Reply-To: References: Message-ID: <56390594.8090709@redhat.com> Sean Conley - US wrote: > Sorry for the redundancy but I thought it would be better to start a new > thread since I am really asking a different question at this point. > > We are trying to stand up an IPA instance using real certs (wildcard) > for our domain, so that external users get a valid cert when coming the > the https UI. I am trying to follow the steps given in this > thread: https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html. > It seems no matter what I do, I end up with: ?full certificate chain is > not present in /etc/ipa/pki/example.org.p12?. Has this process been > documented more completely anywhere? Is this still a valid process? > > I know that there is now an ?external-ca option to ipa-server-install, > but I have questions about the CSR process from my CA and they are not > being very responsive. I have also been told that this option would > require a reseller arrangement potentially costing a lot of money we > don?t want to be in the CA business we just want our external users to > be able to securely access IPA. > > Thanks again in advance for any assistance. I think you misunderstand what the external-ca option does. This generates a CSR that you hand off to an external CA which issues a subordinate CA certificate. This isn't what you want AFAICT. Start reading here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-ca-options.html and it sounds like this is the configuration you want: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-ca-options.html#install-ca-less rob From th at casalogic.dk Tue Nov 3 19:06:49 2015 From: th at casalogic.dk (Troels Hansen) Date: Tue, 3 Nov 2015 20:06:49 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151103123604.GD22483@p.redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> Message-ID: <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> Hi, I got a bit further. I fount the error, being that I had some groups from the old LDAP with gid aroud 500, and current ID range i IPA sat to start at 2000, which was my start UID on the old LDAP. Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I can't find it saved in the LDAP anywhere? ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote: > On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote: >> Hi again, so I finally got time to look further into this. >> >> This task works: >> >> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config >> add:objectclass:top,extensibleObject >> add:cn:$TIME-$FQDN-$LIBARCH >> add:nsslapd-basedn:"$SUFFIX" >> add:delay:0 >> add:ttl:3600 >> >> However, the task gets generated, but no output can be pulled from the task: >> >> ldapsearch -D "cn=Directory Manager" -W -b >> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base >> >> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config >> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config >> objectClass: top >> objectClass: extensibleObject >> nsslapd-basedn: dc=casalogic,dc=lan >> delay: 0 >> cn: 1446551851-kenai.casalogic.lan-64 >> ttl: 3600 >> nstaskcurrentitem: 1 >> nstasktotalitems: 1 >> nstaskexitcode: 32 >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: >> >> Only a exitcode 32 >> The nstaskcurrentitem and nstasktotalitems remains the same till the task >> disappeares. >> Any way do debug these taske further to find out which user it stops at, as it >> looks like it detects an error at one user and stops the task? > > You can activate 'Plug-in debugging' by setting the > nsslapd-errorlog-level attribute of cn=config to 65536, see > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for > details. Make sure to switch it back to 0 after running the sidgen task > because the logging is quite expensive. > > HTH > > bye, > Sumit > >> >> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: >> >> > On Fri, 30 Oct 2015, Troels Hansen wrote: >> >> >> >> >> >> >> >>> I think it should be >> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX >> >>> not >> >>> add:basedn:"cn=accounts,$SUFFIX" >> >>> >> >>> this is what sidgen task expects and it returns constraint violation >> >>> error if parameters are wrong: >> >>> >> >>> str = fetch_attr(e, "nsslapd-basedn", NULL); >> >>> if (str == NULL) { >> >>> LOG_FATAL("Missing nsslapd-basedn!\n"); >> >>> *returncode = LDAP_CONSTRAINT_VIOLATION; >> >>> ret = SLAPI_DSE_CALLBACK_ERROR; >> >>> goto done; >> >>> } >> >>> >> >> >> >>I think you are right. >> >>Don't know what I have tested, but it brings me a different error, that I didn't >> >>see before: >> >> >> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: >> >>{'desc': 'Operations error'} >> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations >> >>error: >> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The >> >>ipa-ldap-updater command was successful >> >> >> >>Where did you find the source for the sidgen task? I could try looking at at it >> >>myself, but can't find it. >> > You can check it here: >> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 >> > >> > -- >> > / Alexander Bokovoy >> >> -- >> Med venlig hilsen >> >> Troels Hansen >> >> Systemkonsulent >> >> Casalogic A/S >> >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. >> >> -- >> 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From ftweedal at redhat.com Tue Nov 3 22:55:46 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 4 Nov 2015 08:55:46 +1000 Subject: [Freeipa-users] using wildcard cert from external CA In-Reply-To: References: Message-ID: <20151103225546.GU20018@dhcp-40-8.bne.redhat.com> On Tue, Nov 03, 2015 at 06:00:52PM +0000, Sean Conley - US wrote: > Sorry for the redundancy but I thought it would be better to start > a new thread since I am really asking a different question at this > point. > > We are trying to stand up an IPA instance using real certs > (wildcard) for our domain, so that external users get a valid cert > when coming the the https UI. I am trying to follow the steps > given in this thread: > https://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html. > It seems no matter what I do, I end up with: "full certificate > chain is not present in /etc/ipa/pki/example.org.p12". Has this > process been documented more completely anywhere? Is this still a > valid process? > > I know that there is now an -external-ca option to > ipa-server-install, but I have questions about the CSR process > from my CA and they are not being very responsive. I have also > been told that this option would require a reseller arrangement > potentially costing a lot of money... we don't want to be in the > CA business... we just want our external users to be able to > securely access IPA. > If you only want publicly trusted certs for HTTP and LDAP you should not use --external-ca. The CSR generated during ipa-server-install when that option is given is for a CA certifiate, not a server (leaf) certificate. For HTTP / LDAP certificate(s) FreeIPA does not generate the CSR for you. But it sounds like you already have your wildcard cert? If so, then you just need to install it using ipa-server-certinstall or the --http_pkcs12 and/or --dirsrv_pkcs12 options in ipa-server-install. HTH, Fraser > Thanks again in advance for any assistance. > > Sean > > From gil at omnigroup.com Wed Nov 4 05:35:42 2015 From: gil at omnigroup.com (Gilbert Wilson) Date: Tue, 3 Nov 2015 21:35:42 -0800 Subject: [Freeipa-users] Python IndexError: list index out of range with ipa-server-install --external-cert-file Message-ID: <38A69A03-997C-4A84-8A8E-898156CB6537@omnigroup.com> Apologies ahead of time as this is my first post to the list and interaction with the FreeIPA project. If I should be taking this question to a different forum please point me in the right direction! The error condition I?m encountering is mentioned a few times on the list, but the threads die off without any conclusions. The most recent mention of it that I could find is here: https://www.redhat.com/archives/freeipa-users/2015-March/msg00271.html It also looks like this has shown up as a bug that was fixed here: https://fedorahosted.org/freeipa/ticket/4397 I?m using CentOS Linux release 7.1.1503 (Core) system running FreeIPA VERSION: 4.1.0, API_VERSION: 2.112. The error happens when attempting to finish an ipa-server-install using a cert signed by an external CA: ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem The install proceeds as normal, but then when trying to create the RA certificate it errors out with: ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range [root at ipa ~]# ipa : DEBUG stderr= all/cainstance.py", line 520, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1149, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range Unlike the bug and thread I linked to above we are not using a Windows CA. Our CA is based on openssl. Since I?m fairly new to FreeIPA I?m not sure what logs would be most helpful to troubleshoot, but my bumbling about seemed to indicate that the the error condition is in the server?s xml-based web api request/response logic. I?m not sure if the error is localized to that part of the system or if there?s some precondition that failed beforehand. The installation is left in a pretty broken/useless state. If I try to run `ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem` again it instructs me that I have to run `ipa-server-install --external-ca` (essentially, start over from scratch). An aside question: is there some way to rerun the setup from where it broke down so that I don?t have to bother our CA admin to sign my CSR each time? That said, I can reliably produce this error condition and am willing to put in some time to do data collection to track it down, and our CA admin is willing to humor me for a little while! But, where do I start? What information would be most useful to collect? Thanks! Gil Gilbert Wilson Systems Administrator The Omni Group +1 206-523-4152 +1 206-523-5896 (Fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sbose at redhat.com Wed Nov 4 08:51:43 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 4 Nov 2015 09:51:43 +0100 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> Message-ID: <20151104085143.GA15215@p.redhat.com> On Tue, Nov 03, 2015 at 08:06:49PM +0100, Troels Hansen wrote: > Hi, I got a bit further. > I fount the error, being that I had some groups from the old LDAP with gid aroud 500, and current ID range i IPA sat to start at 2000, which was my start UID on the old LDAP. The SIDs are generated based on the UID or GID and the data from a matching idrange, see http://www.freeipa.org/page/V3/ID_Ranges for details about the idranges. To get SIDs assigned to the old entries you have to add a new idrange for the local user: ipa idrange-add ----type=ipa-local --base-id=500 --range-size=100 --rid-base=1000000 --secondary-rid-base=1000200 With this the UIDs and GIDs between 500 and 600 will get SIDs with RIDs in the range from 1000000 to 1000100 (see kine above why there is a secondard RID base). > > Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I can't find it saved in the LDAP anywhere? New IDs are assigned by the DNS plugin, please see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Managing-Unique_UID_and_GID_Attributes.html and http://directory.fedoraproject.org/docs/389ds/design/dna-plugin.html for details. Please note that although they are somewhat related there currently is no automatic configuration of the ranges used by the DNA plugin and the ranges managed by the 'ipa idrange-*' utility. There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix this. HTH bye, Sumit > > ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote: > > > On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote: > >> Hi again, so I finally got time to look further into this. > >> > >> This task works: > >> > >> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config > >> add:objectclass:top,extensibleObject > >> add:cn:$TIME-$FQDN-$LIBARCH > >> add:nsslapd-basedn:"$SUFFIX" > >> add:delay:0 > >> add:ttl:3600 > >> > >> However, the task gets generated, but no output can be pulled from the task: > >> > >> ldapsearch -D "cn=Directory Manager" -W -b > >> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' > >> Enter LDAP Password: > >> # extended LDIF > >> # > >> # LDAPv3 > >> # base > >> > >> with scope subtree > >> # filter: (objectclass=*) > >> # requesting: ALL > >> # > >> > >> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config > >> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config > >> objectClass: top > >> objectClass: extensibleObject > >> nsslapd-basedn: dc=casalogic,dc=lan > >> delay: 0 > >> cn: 1446551851-kenai.casalogic.lan-64 > >> ttl: 3600 > >> nstaskcurrentitem: 1 > >> nstasktotalitems: 1 > >> nstaskexitcode: 32 > >> > >> # search result > >> search: 2 > >> result: 0 Success > >> > >> # numResponses: 2 > >> # numEntries: > >> > >> Only a exitcode 32 > >> The nstaskcurrentitem and nstasktotalitems remains the same till the task > >> disappeares. > >> Any way do debug these taske further to find out which user it stops at, as it > >> looks like it detects an error at one user and stops the task? > > > > You can activate 'Plug-in debugging' by setting the > > nsslapd-errorlog-level attribute of cn=config to 65536, see > > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for > > details. Make sure to switch it back to 0 after running the sidgen task > > because the logging is quite expensive. > > > > HTH > > > > bye, > > Sumit > > > >> > >> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: > >> > >> > On Fri, 30 Oct 2015, Troels Hansen wrote: > >> >> > >> >> > >> >> > >> >>> I think it should be > >> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX > >> >>> not > >> >>> add:basedn:"cn=accounts,$SUFFIX" > >> >>> > >> >>> this is what sidgen task expects and it returns constraint violation > >> >>> error if parameters are wrong: > >> >>> > >> >>> str = fetch_attr(e, "nsslapd-basedn", NULL); > >> >>> if (str == NULL) { > >> >>> LOG_FATAL("Missing nsslapd-basedn!\n"); > >> >>> *returncode = LDAP_CONSTRAINT_VIOLATION; > >> >>> ret = SLAPI_DSE_CALLBACK_ERROR; > >> >>> goto done; > >> >>> } > >> >>> > >> >> > >> >>I think you are right. > >> >>Don't know what I have tested, but it brings me a different error, that I didn't > >> >>see before: > >> >> > >> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: > >> >>{'desc': 'Operations error'} > >> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations > >> >>error: > >> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The > >> >>ipa-ldap-updater command was successful > >> >> > >> >>Where did you find the source for the sidgen task? I could try looking at at it > >> >>myself, but can't find it. > >> > You can check it here: > >> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 > >> > > >> > -- > >> > / Alexander Bokovoy > >> > >> -- > >> Med venlig hilsen > >> > >> Troels Hansen > >> > >> Systemkonsulent > >> > >> Casalogic A/S > >> > >> > >> T (+45) 70 20 10 63 > >> > >> M (+45) 22 43 71 57 > >> > >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > >> meget mere. > >> > >> -- > >> 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > > -- > 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 From prashant at apigee.com Wed Nov 4 09:07:18 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 4 Nov 2015 14:37:18 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 Message-ID: Hi All, We rolled out freeipa in our setup somewhere in beginning of 2015. Since then there have been couple of new releases. Latest being 4.2.3. The FreeIPA servers are installed on Fedora 21 hosts and at this point there is no direct way of upgrading to 4.2.3 unless we also upgrade the OS. The COPR repos do not support Fedora 21. Is there a way to get the latest freeipa WITHOUT upgrading the OS ? Since Fedora releases a new version approx every 6 months, how are others handling the upgrades ? Please let me know. Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Wed Nov 4 09:15:42 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 4 Nov 2015 10:15:42 +0100 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: References: Message-ID: <20151104091541.GF12746@mail.corp.redhat.com> On (04/11/15 14:37), Prashant Bapat wrote: >Hi All, > >We rolled out freeipa in our setup somewhere in beginning of 2015. Since >then there have been couple of new releases. Latest being 4.2.3. > >The FreeIPA servers are installed on Fedora 21 hosts and at this point >there is no direct way of upgrading to 4.2.3 unless we also upgrade the OS. >The COPR repos do not support Fedora 21. > Fedora 23 was released yesterday. It means then Fedora 21 will be out of support in a month. I would definitelly recomment to upgrade it to newer Fedora. If you do not want t upgrade so often you might use FreeIPA on CentOS 7 LS From mkosek at redhat.com Wed Nov 4 09:22:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 4 Nov 2015 10:22:22 +0100 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: <20151104091541.GF12746@mail.corp.redhat.com> References: <20151104091541.GF12746@mail.corp.redhat.com> Message-ID: <5639CE4E.9070302@redhat.com> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: > On (04/11/15 14:37), Prashant Bapat wrote: >> Hi All, >> >> We rolled out freeipa in our setup somewhere in beginning of 2015. Since >> then there have been couple of new releases. Latest being 4.2.3. >> >> The FreeIPA servers are installed on Fedora 21 hosts and at this point >> there is no direct way of upgrading to 4.2.3 unless we also upgrade the OS. >> The COPR repos do not support Fedora 21. >> > Fedora 23 was released yesterday. > It means then Fedora 21 will be out of support in a month. > I would definitelly recomment to upgrade it to newer Fedora. +1. I did the same actually for FreeIPA demo which was also running on F21 before: http://www.freeipa.org/page/Demo I had to do it in two steps: F21->F22, F22->F23. If you make sure that F22->F23 upgrade updates to freeipa-4.2.3-1.fc23 or later (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it should work just fine. > If you do not want t upgrade so often you might use FreeIPA > on CentOS 7 > > LS > From prashant at apigee.com Wed Nov 4 09:27:15 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 4 Nov 2015 14:57:15 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: <5639CE4E.9070302@redhat.com> References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> Message-ID: Ack. But in a live replicated setup wont upgrading from F21->F22 and F22->F23 take a long time. I mean couple of hours ? Are there any other ways to do this. Perhaps do a fresh install of F23 and then restore data from FreeIPA 4.1.4 (F21) ? On 4 November 2015 at 14:52, Martin Kosek wrote: > On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: > > On (04/11/15 14:37), Prashant Bapat wrote: > >> Hi All, > >> > >> We rolled out freeipa in our setup somewhere in beginning of 2015. Since > >> then there have been couple of new releases. Latest being 4.2.3. > >> > >> The FreeIPA servers are installed on Fedora 21 hosts and at this point > >> there is no direct way of upgrading to 4.2.3 unless we also upgrade the > OS. > >> The COPR repos do not support Fedora 21. > >> > > Fedora 23 was released yesterday. > > It means then Fedora 21 will be out of support in a month. > > I would definitelly recomment to upgrade it to newer Fedora. > > +1. I did the same actually for FreeIPA demo which was also running on F21 > before: > http://www.freeipa.org/page/Demo > I had to do it in two steps: F21->F22, F22->F23. > > If you make sure that F22->F23 upgrade updates to freeipa-4.2.3-1.fc23 or > later > (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it > should > work just fine. > > > If you do not want t upgrade so often you might use FreeIPA > > on CentOS 7 > > > > LS > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Nov 4 09:32:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 4 Nov 2015 10:32:09 +0100 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> Message-ID: <5639D099.5020104@redhat.com> On 11/04/2015 10:27 AM, Prashant Bapat wrote: > Ack. But in a live replicated setup wont upgrading from F21->F22 and > F22->F23 take a long time. I mean couple of hours ? It will take some outage time, yes. But if you have appropriate number of replicas and are upgrading one by one, you should be fine - the clients should fail over to other replicas. > Are there any other ways to do this. Perhaps do a fresh install of F23 and > then restore data from FreeIPA 4.1.4 (F21) ? FreeIPA upgrade also updates the data themselves. Restoring old data and configuration files on fresh F23 using full backup + running the upgrade may work, but there may be also a lot of hurdles. It is not really a tested approach. > > On 4 November 2015 at 14:52, Martin Kosek wrote: > >> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: >>> On (04/11/15 14:37), Prashant Bapat wrote: >>>> Hi All, >>>> >>>> We rolled out freeipa in our setup somewhere in beginning of 2015. Since >>>> then there have been couple of new releases. Latest being 4.2.3. >>>> >>>> The FreeIPA servers are installed on Fedora 21 hosts and at this point >>>> there is no direct way of upgrading to 4.2.3 unless we also upgrade the >> OS. >>>> The COPR repos do not support Fedora 21. >>>> >>> Fedora 23 was released yesterday. >>> It means then Fedora 21 will be out of support in a month. >>> I would definitelly recomment to upgrade it to newer Fedora. >> >> +1. I did the same actually for FreeIPA demo which was also running on F21 >> before: >> http://www.freeipa.org/page/Demo >> I had to do it in two steps: F21->F22, F22->F23. >> >> If you make sure that F22->F23 upgrade updates to freeipa-4.2.3-1.fc23 or >> later >> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it >> should >> work just fine. >> >>> If you do not want t upgrade so often you might use FreeIPA >>> on CentOS 7 >>> >>> LS >>> >> >> > From andrew.holway at gmail.com Wed Nov 4 10:22:37 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Wed, 4 Nov 2015 11:22:37 +0100 Subject: [Freeipa-users] Server used in DOS attack on UDP port 0 Message-ID: Hi, One of our AWS machines was used in an DOS attack last night and I am looking for possible attack vectors. AWS tells me it was sending UDP port 0 traffic to a cloudflare address. This instance had an incorrectly configured AWS security group exposing all ports. The server in question is a Centos 7 based FreeIPA server, OpenVPN concentrator and DNS server. With a brief inspection before the instance was stopped no evidence of intrusion could be detected in the obvious places and the machine is protected by standard SELinux policies. On this machine Firewalld is currently configured with a single zone with masquerade enabled firewalld config. public (default, active) interfaces: eth0 sources: services: dhcpv6-client dns http https kerberos kpasswd ldap ldaps ntp openvpn ssh ports: 81/tcp masquerade: yes forward-ports: icmp-blocks: rich rules: Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 4 13:47:47 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 08:47:47 -0500 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: <5639D099.5020104@redhat.com> References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> <5639D099.5020104@redhat.com> Message-ID: <563A0C83.3040402@redhat.com> Martin Kosek wrote: > On 11/04/2015 10:27 AM, Prashant Bapat wrote: >> Ack. But in a live replicated setup wont upgrading from F21->F22 and >> F22->F23 take a long time. I mean couple of hours ? > > It will take some outage time, yes. But if you have appropriate number of > replicas and are upgrading one by one, you should be fine - the clients should > fail over to other replicas. > >> Are there any other ways to do this. Perhaps do a fresh install of F23 and >> then restore data from FreeIPA 4.1.4 (F21) ? > > FreeIPA upgrade also updates the data themselves. Restoring old data and > configuration files on fresh F23 using full backup + running the upgrade may > work, but there may be also a lot of hurdles. It is not really a tested approach. Or he could one by one install a new F23 system and configure it as a new master to replace one of the old ones until they are all running F23. I'm pretty sure backup/restore only works within the same version. rob > >> >> On 4 November 2015 at 14:52, Martin Kosek wrote: >> >>> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: >>>> On (04/11/15 14:37), Prashant Bapat wrote: >>>>> Hi All, >>>>> >>>>> We rolled out freeipa in our setup somewhere in beginning of 2015. Since >>>>> then there have been couple of new releases. Latest being 4.2.3. >>>>> >>>>> The FreeIPA servers are installed on Fedora 21 hosts and at this point >>>>> there is no direct way of upgrading to 4.2.3 unless we also upgrade the >>> OS. >>>>> The COPR repos do not support Fedora 21. >>>>> >>>> Fedora 23 was released yesterday. >>>> It means then Fedora 21 will be out of support in a month. >>>> I would definitelly recomment to upgrade it to newer Fedora. >>> >>> +1. I did the same actually for FreeIPA demo which was also running on F21 >>> before: >>> http://www.freeipa.org/page/Demo >>> I had to do it in two steps: F21->F22, F22->F23. >>> >>> If you make sure that F22->F23 upgrade updates to freeipa-4.2.3-1.fc23 or >>> later >>> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it >>> should >>> work just fine. >>> >>>> If you do not want t upgrade so often you might use FreeIPA >>>> on CentOS 7 >>>> >>>> LS >>>> >>> >>> >> > From rcritten at redhat.com Wed Nov 4 13:49:49 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 08:49:49 -0500 Subject: [Freeipa-users] Python IndexError: list index out of range with ipa-server-install --external-cert-file In-Reply-To: <38A69A03-997C-4A84-8A8E-898156CB6537@omnigroup.com> References: <38A69A03-997C-4A84-8A8E-898156CB6537@omnigroup.com> Message-ID: <563A0CFD.2030901@redhat.com> Gilbert Wilson wrote: > Apologies ahead of time as this is my first post to the list and interaction with the FreeIPA project. If I should be taking this question to a different forum please point me in the right direction! > > The error condition I?m encountering is mentioned a few times on the list, but the threads die off without any conclusions. The most recent mention of it that I could find is here: > > https://www.redhat.com/archives/freeipa-users/2015-March/msg00271.html > > It also looks like this has shown up as a bug that was fixed here: > > https://fedorahosted.org/freeipa/ticket/4397 > > I?m using CentOS Linux release 7.1.1503 (Core) system running FreeIPA VERSION: 4.1.0, API_VERSION: 2.112. > > The error happens when attempting to finish an ipa-server-install using a cert signed by an external CA: > > ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem > > The install proceeds as normal, but then when trying to create the RA certificate it errors out with: > > ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range > Unexpected error - see /var/log/ipaserver-install.log for details: > IndexError: list index out of range > [root at ipa ~]# ipa : DEBUG stderr= > all/cainstance.py", line 520, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation > run_step(full_msg, method) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1149, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > > ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range > Unexpected error - see /var/log/ipaserver-install.log for details: > IndexError: list index out of range > > Unlike the bug and thread I linked to above we are not using a Windows CA. Our CA is based on openssl. Since I?m fairly new to FreeIPA I?m not sure what logs would be most helpful to troubleshoot, but my bumbling about seemed to indicate that the the error condition is in the server?s xml-based web api request/response logic. I?m not sure if the error is localized to that part of the system or if there?s some precondition that failed beforehand. The installation is left in a pretty broken/useless state. If I try to run `ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem` again it instructs me that I have to run `ipa-server-install --external-ca` (essentially, start over from scratch). An aside question: is there some way to rerun the setup from where it broke down so that I don?t have to bother our CA admin to sign my CSR each time? That said, I can reliably produce this error condition and am willing! to put in some time to do data collection to track it down, and our CA admin is willing to humor me for a little while! But, where do I start? What information would be most useful to collect? You're seeing a symptom, not the problem. You'd need to look at the install log referenced above plus the debug log somewhere in /var/log/pki/pki-ca/ And unfortunately right now you need to start over after a failed install. rob rob From cal-s at blue-bolt.com Wed Nov 4 13:50:54 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Wed, 4 Nov 2015 13:50:54 +0000 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds Message-ID: <563A0D3E.4020009@blue-bolt.com> Hi Very new to IPA and setting up a proof of concept system that i hope will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to import People, Group ou's into IPA using "ipa migrate-ds". The IPA and existing LDAP directories have different BaseDNs (eg ipadomain.local on IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a completely new directory that we will then switch our clients over to. ipa migrate-ds --schema=RFC2307 --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 whatever i try (w or w/o --schema=RFC2307) , the response is the same: ipa: ERROR: Insufficient access: Invalid credentials or with a verbose flag: ipa: INFO: Forwarding 'migrate_ds' to server u'https://ipa.ipadomain.local/ipa/session/xml' ipa: ERROR: Insufficient access: Invalid credentials manager naturally exists in ldapdomain.local and i've definitely supplied the correct password (we use the same creds to manage LDAP using phpldapadmin) Hoping that someone has some experience with this and can point me in the right direction? thanks -- Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com From rcritten at redhat.com Wed Nov 4 13:56:24 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 08:56:24 -0500 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563A0D3E.4020009@blue-bolt.com> References: <563A0D3E.4020009@blue-bolt.com> Message-ID: <563A0E88.90705@redhat.com> Cal Sawyer wrote: > Hi > > Very new to IPA and setting up a proof of concept system that i hope > will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to > import People, Group ou's into IPA using "ipa migrate-ds". The IPA and > existing LDAP directories have different BaseDNs (eg ipadomain.local on > IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a > completely new directory that we will then switch our clients over to. > > ipa migrate-ds --schema=RFC2307 > --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 > > whatever i try (w or w/o --schema=RFC2307) , the response is the same: > > ipa: ERROR: Insufficient access: Invalid credentials > > or with a verbose flag: > > ipa: INFO: Forwarding 'migrate_ds' to server > u'https://ipa.ipadomain.local/ipa/session/xml' > ipa: ERROR: Insufficient access: Invalid credentials > > manager naturally exists in ldapdomain.local and i've definitely > supplied the correct password (we use the same creds to manage LDAP > using phpldapadmin) > > Hoping that someone has some experience with this and can point me in > the right direction? It is binding to openldap using cn=Directory Manager. If your admin user that can read userPassword is named something different then pass it in using the --binddn option. rob From th at casalogic.dk Wed Nov 4 14:34:49 2015 From: th at casalogic.dk (Troels Hansen) Date: Wed, 4 Nov 2015 15:34:49 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> Message-ID: <688888716.8428825.1446647689417.JavaMail.zimbra@casalogic.dk> OK, i have gotten my SID generation to run. However, on the migrated users I'm unable to do a pdbedit -L I get: pdbedit -Lv th doing parameter max log size = 50 doing parameter add machine script = /usr/sbin/smbldap-useradd -w "%u" doing parameter socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 doing parameter printing = cups doing parameter printcap name = /etc/printcap doing parameter load printers = no pm_process() returned Yes No builtin backend found, trying to load plugin Module 'ipasam' loaded smbldap_open_connection: connection opened ldap_connect_system: successful connection to the LDAP server The LDAP server is successfully connected pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan init_sam_from_ldap: Entry found for user: th Segmentation fault on the users generated directly in IPA it works. [root at tinkerbell ~]# pdbedit -Lv kk I get the same error when calling pdbedit on IPA or differnet Samba server connected with ipasam. Only difference I can see is that the users causing segfault have a RID from primary range, and the users working have from secondary range, so I suspect that something have gone wrong in my shifting round in the ranges and this somehow causes ipasam to segfault. Could I just delete the ipaNTSecurityIdentifier directly in LDAP and let the SID generation run again, or do someone have a good idea to have the SID's reset? ----- On Nov 3, 2015, at 8:06 PM, Troels Hansen th at casalogic.dk wrote: > Hi, I got a bit further. > I fount the error, being that I had some groups from the old LDAP with gid aroud > 500, and current ID range i IPA sat to start at 2000, which was my start UID on > the old LDAP. > > Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I > can't find it saved in the LDAP anywhere? > > ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote: > >> On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote: >>> Hi again, so I finally got time to look further into this. >>> >>> This task works: >>> >>> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config >>> add:objectclass:top,extensibleObject >>> add:cn:$TIME-$FQDN-$LIBARCH >>> add:nsslapd-basedn:"$SUFFIX" >>> add:delay:0 >>> add:ttl:3600 >>> >>> However, the task gets generated, but no output can be pulled from the task: >>> >>> ldapsearch -D "cn=Directory Manager" -W -b >>> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base >>> >>> with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config >>> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config >>> objectClass: top >>> objectClass: extensibleObject >>> nsslapd-basedn: dc=casalogic,dc=lan >>> delay: 0 >>> cn: 1446551851-kenai.casalogic.lan-64 >>> ttl: 3600 >>> nstaskcurrentitem: 1 >>> nstasktotalitems: 1 >>> nstaskexitcode: 32 >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: >>> >>> Only a exitcode 32 >>> The nstaskcurrentitem and nstasktotalitems remains the same till the task >>> disappeares. >>> Any way do debug these taske further to find out which user it stops at, as it >>> looks like it detects an error at one user and stops the task? >> >> You can activate 'Plug-in debugging' by setting the >> nsslapd-errorlog-level attribute of cn=config to 65536, see >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for >> details. Make sure to switch it back to 0 after running the sidgen task >> because the logging is quite expensive. >> >> HTH >> >> bye, >> Sumit >> >>> >>> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: >>> >>> > On Fri, 30 Oct 2015, Troels Hansen wrote: >>> >> >>> >> >>> >> >>> >>> I think it should be >>> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX >>> >>> not >>> >>> add:basedn:"cn=accounts,$SUFFIX" >>> >>> >>> >>> this is what sidgen task expects and it returns constraint violation >>> >>> error if parameters are wrong: >>> >>> >>> >>> str = fetch_attr(e, "nsslapd-basedn", NULL); >>> >>> if (str == NULL) { >>> >>> LOG_FATAL("Missing nsslapd-basedn!\n"); >>> >>> *returncode = LDAP_CONSTRAINT_VIOLATION; >>> >>> ret = SLAPI_DSE_CALLBACK_ERROR; >>> >>> goto done; >>> >>> } >>> >>> >>> >> >>> >>I think you are right. >>> >>Don't know what I have tested, but it brings me a different error, that I didn't >>> >>see before: >>> >> >>> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: >>> >>{'desc': 'Operations error'} >>> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations >>> >>error: >>> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The >>> >>ipa-ldap-updater command was successful >>> >> >>> >>Where did you find the source for the sidgen task? I could try looking at at it >>> >>myself, but can't find it. >>> > You can check it here: >>> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 >>> > >>> > -- >>> > / Alexander Bokovoy >>> >>> -- >>> Med venlig hilsen >>> >>> Troels Hansen >>> >>> Systemkonsulent >>> >>> Casalogic A/S >>> >>> >>> T (+45) 70 20 10 63 >>> >>> M (+45) 22 43 71 57 >>> >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>> meget mere. >>> >>> -- >>> 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > meget mere. > > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From sbose at redhat.com Wed Nov 4 15:03:46 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 4 Nov 2015 16:03:46 +0100 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <688888716.8428825.1446647689417.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> <688888716.8428825.1446647689417.JavaMail.zimbra@casalogic.dk> Message-ID: <20151104150346.GC3586@p.redhat.com> On Wed, Nov 04, 2015 at 03:34:49PM +0100, Troels Hansen wrote: > OK, i have gotten my SID generation to run. > However, on the migrated users I'm unable to do a pdbedit -L > I get: > > pdbedit -Lv th do you see any more details if you run pdbedit with '-d 255' ? > doing parameter max log size = 50 > doing parameter add machine script = /usr/sbin/smbldap-useradd -w "%u" > doing parameter socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 > doing parameter printing = cups > doing parameter printcap name = /etc/printcap > doing parameter load printers = no > pm_process() returned Yes > No builtin backend found, trying to load plugin > Module 'ipasam' loaded > smbldap_open_connection: connection opened > ldap_connect_system: successful connection to the LDAP server > The LDAP server is successfully connected > pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan > init_sam_from_ldap: Entry found for user: th > Segmentation fault Can you send me a full backtrace of the core or the whole core file with the version of the samba.common package? > > on the users generated directly in IPA it works. > > [root at tinkerbell ~]# pdbedit -Lv kk > > I get the same error when calling pdbedit on IPA or differnet Samba server connected with ipasam. > > Only difference I can see is that the users causing segfault have a RID from primary range, and the users working have from secondary range, so I suspect that something have gone wrong in my shifting round in the ranges and this somehow causes ipasam to segfault. > > Could I just delete the ipaNTSecurityIdentifier directly in LDAP and let the SID generation run again, or do someone have a good idea to have the SID's reset? You can try but I doubt that it will help. ipasam was written primarily with the IPA use-case in mind, so chance are that we run into some unexpected behaviour when it is used in other context. Nevertheless it should be fixed if there is an issue in ipasam. bye, Sumit > > ----- On Nov 3, 2015, at 8:06 PM, Troels Hansen th at casalogic.dk wrote: > > > Hi, I got a bit further. > > I fount the error, being that I had some groups from the old LDAP with gid aroud > > 500, and current ID range i IPA sat to start at 2000, which was my start UID on > > the old LDAP. > > > > Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I > > can't find it saved in the LDAP anywhere? > > > > ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote: > > > >> On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote: > >>> Hi again, so I finally got time to look further into this. > >>> > >>> This task works: > >>> > >>> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config > >>> add:objectclass:top,extensibleObject > >>> add:cn:$TIME-$FQDN-$LIBARCH > >>> add:nsslapd-basedn:"$SUFFIX" > >>> add:delay:0 > >>> add:ttl:3600 > >>> > >>> However, the task gets generated, but no output can be pulled from the task: > >>> > >>> ldapsearch -D "cn=Directory Manager" -W -b > >>> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config' > >>> Enter LDAP Password: > >>> # extended LDIF > >>> # > >>> # LDAPv3 > >>> # base > >>> > >>> with scope subtree > >>> # filter: (objectclass=*) > >>> # requesting: ALL > >>> # > >>> > >>> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config > >>> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config > >>> objectClass: top > >>> objectClass: extensibleObject > >>> nsslapd-basedn: dc=casalogic,dc=lan > >>> delay: 0 > >>> cn: 1446551851-kenai.casalogic.lan-64 > >>> ttl: 3600 > >>> nstaskcurrentitem: 1 > >>> nstasktotalitems: 1 > >>> nstaskexitcode: 32 > >>> > >>> # search result > >>> search: 2 > >>> result: 0 Success > >>> > >>> # numResponses: 2 > >>> # numEntries: > >>> > >>> Only a exitcode 32 > >>> The nstaskcurrentitem and nstasktotalitems remains the same till the task > >>> disappeares. > >>> Any way do debug these taske further to find out which user it stops at, as it > >>> looks like it detects an error at one user and stops the task? > >> > >> You can activate 'Plug-in debugging' by setting the > >> nsslapd-errorlog-level attribute of cn=config to 65536, see > >> http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for > >> details. Make sure to switch it back to 0 after running the sidgen task > >> because the logging is quite expensive. > >> > >> HTH > >> > >> bye, > >> Sumit > >> > >>> > >>> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote: > >>> > >>> > On Fri, 30 Oct 2015, Troels Hansen wrote: > >>> >> > >>> >> > >>> >> > >>> >>> I think it should be > >>> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX > >>> >>> not > >>> >>> add:basedn:"cn=accounts,$SUFFIX" > >>> >>> > >>> >>> this is what sidgen task expects and it returns constraint violation > >>> >>> error if parameters are wrong: > >>> >>> > >>> >>> str = fetch_attr(e, "nsslapd-basedn", NULL); > >>> >>> if (str == NULL) { > >>> >>> LOG_FATAL("Missing nsslapd-basedn!\n"); > >>> >>> *returncode = LDAP_CONSTRAINT_VIOLATION; > >>> >>> ret = SLAPI_DSE_CALLBACK_ERROR; > >>> >>> goto done; > >>> >>> } > >>> >>> > >>> >> > >>> >>I think you are right. > >>> >>Don't know what I have tested, but it brings me a different error, that I didn't > >>> >>see before: > >>> >> > >>> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: > >>> >>{'desc': 'Operations error'} > >>> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations > >>> >>error: > >>> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The > >>> >>ipa-ldap-updater command was successful > >>> >> > >>> >>Where did you find the source for the sidgen task? I could try looking at at it > >>> >>myself, but can't find it. > >>> > You can check it here: > >>> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 > >>> > > >>> > -- > >>> > / Alexander Bokovoy > >>> > >>> -- > >>> Med venlig hilsen > >>> > >>> Troels Hansen > >>> > >>> Systemkonsulent > >>> > >>> Casalogic A/S > >>> > >>> > >>> T (+45) 70 20 10 63 > >>> > >>> M (+45) 22 43 71 57 > >>> > >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > >>> meget mere. > >>> > >>> -- > >>> 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 > > > > -- > > Med venlig hilsen > > > > Troels Hansen > > > > Systemkonsulent > > > > Casalogic A/S > > > > > > T (+45) 70 20 10 63 > > > > M (+45) 22 43 71 57 > > > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > > meget mere. > > > > -- > > 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 > > -- > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > > -- > 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 From cal-s at blue-bolt.com Wed Nov 4 15:11:56 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Wed, 4 Nov 2015 15:11:56 +0000 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563A0E88.90705@redhat.com> References: <563A0D3E.4020009@blue-bolt.com> <563A0E88.90705@redhat.com> Message-ID: <563A203C.8030601@blue-bolt.com> That's terrific, Rob - thanks very much. Users and Groups import smoothly with a little additional tweaking ipa -v migrate-ds --with-compat --bind-dn="cn=Manager,dc=ldapdomain,dc=local" --user-container="ou=People,dc=blue-bolt,dc=local" --group-container="ou=Group,dc=ldapdomain,dc=local" --group-objectclass="posixGroup" ldap://1.2.3.4:389 boom, all users and groups imported ... but without group membership. The structure of Group in OpenLDAP is: # power, Group, ldapdomain.local dn: cn=systems,ou=Group,dc=ldapdomain,dc=local cn: systems gidNumber: 1112 objectClass: posixGroup memberUid: usera memberUid: userb and IPA's schema appears, with one exception (objectClass: top), to match: # admins, groups, compat, ipadomain.local dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local objectClass: posixGroup objectClass: top gidNumber: 1944000000 memberUid: admin cn: admins A side question: can i use migrate-ds to bring in automount and sudoer maps from OpenLDAP? thanks again Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com On 04/11/15 13:56, Rob Crittenden wrote: > Cal Sawyer wrote: >> Hi >> >> Very new to IPA and setting up a proof of concept system that i hope >> will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to >> import People, Group ou's into IPA using "ipa migrate-ds". The IPA and >> existing LDAP directories have different BaseDNs (eg ipadomain.local on >> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a >> completely new directory that we will then switch our clients over to. >> >> ipa migrate-ds --schema=RFC2307 >> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 >> >> whatever i try (w or w/o --schema=RFC2307) , the response is the same: >> >> ipa: ERROR: Insufficient access: Invalid credentials >> >> or with a verbose flag: >> >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'https://ipa.ipadomain.local/ipa/session/xml' >> ipa: ERROR: Insufficient access: Invalid credentials >> >> manager naturally exists in ldapdomain.local and i've definitely >> supplied the correct password (we use the same creds to manage LDAP >> using phpldapadmin) >> >> Hoping that someone has some experience with this and can point me in >> the right direction? > It is binding to openldap using cn=Directory Manager. If your admin user > that can read userPassword is named something different then pass it in > using the --binddn option. > > rob > From mkosek at redhat.com Wed Nov 4 15:22:48 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 4 Nov 2015 16:22:48 +0100 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563A203C.8030601@blue-bolt.com> References: <563A0D3E.4020009@blue-bolt.com> <563A0E88.90705@redhat.com> <563A203C.8030601@blue-bolt.com> Message-ID: <563A22C8.7050008@redhat.com> On 11/04/2015 04:11 PM, Cal Sawyer wrote: > That's terrific, Rob - thanks very much. Users and Groups import smoothly with > a little additional tweaking > > ipa -v migrate-ds --with-compat --bind-dn="cn=Manager,dc=ldapdomain,dc=local" > --user-container="ou=People,dc=blue-bolt,dc=local" > --group-container="ou=Group,dc=ldapdomain,dc=local" > --group-objectclass="posixGroup" ldap://1.2.3.4:389 > > boom, all users and groups imported ... but without group membership. > > The structure of Group in OpenLDAP is: > > # power, Group, ldapdomain.local > dn: cn=systems,ou=Group,dc=ldapdomain,dc=local > cn: systems > gidNumber: 1112 > objectClass: posixGroup > memberUid: usera > memberUid: userb > > > and IPA's schema appears, with one exception (objectClass: top), to match: > > # admins, groups, compat, ipadomain.local > dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local > objectClass: posixGroup > objectClass: top > gidNumber: 1944000000 > memberUid: admin > cn: admins You should be able to use option --schema=RFC2307. More on "ipa help migrate-ds". > A side question: can i use migrate-ds to bring in automount and sudoer maps > from OpenLDAP? There is command "automountlocation-import" if you can export OpenLDAP maps to files. Otherwise you would need to export the data from OpenLDAP, massage it a little and then either import it into FreeIPA direcly if you confident that you have the format right or process it with some script and upload with ipa commands, if you want to be sure the target format is right. > > thanks again > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 | www.blue-bolt.com > > On 04/11/15 13:56, Rob Crittenden wrote: >> Cal Sawyer wrote: >>> Hi >>> >>> Very new to IPA and setting up a proof of concept system that i hope >>> will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to >>> import People, Group ou's into IPA using "ipa migrate-ds". The IPA and >>> existing LDAP directories have different BaseDNs (eg ipadomain.local on >>> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a >>> completely new directory that we will then switch our clients over to. >>> >>> ipa migrate-ds --schema=RFC2307 >>> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 >>> >>> whatever i try (w or w/o --schema=RFC2307) , the response is the same: >>> >>> ipa: ERROR: Insufficient access: Invalid credentials >>> >>> or with a verbose flag: >>> >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'https://ipa.ipadomain.local/ipa/session/xml' >>> ipa: ERROR: Insufficient access: Invalid credentials >>> >>> manager naturally exists in ldapdomain.local and i've definitely >>> supplied the correct password (we use the same creds to manage LDAP >>> using phpldapadmin) >>> >>> Hoping that someone has some experience with this and can point me in >>> the right direction? >> It is binding to openldap using cn=Directory Manager. If your admin user >> that can read userPassword is named something different then pass it in >> using the --binddn option. >> >> rob >> > From rcritten at redhat.com Wed Nov 4 15:37:14 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 10:37:14 -0500 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563A203C.8030601@blue-bolt.com> References: <563A0D3E.4020009@blue-bolt.com> <563A0E88.90705@redhat.com> <563A203C.8030601@blue-bolt.com> Message-ID: <563A262A.3050207@redhat.com> Cal Sawyer wrote: > That's terrific, Rob - thanks very much. Users and Groups import > smoothly with a little additional tweaking > > ipa -v migrate-ds --with-compat > --bind-dn="cn=Manager,dc=ldapdomain,dc=local" > --user-container="ou=People,dc=blue-bolt,dc=local" > --group-container="ou=Group,dc=ldapdomain,dc=local" > --group-objectclass="posixGroup" ldap://1.2.3.4:389 > > boom, all users and groups imported ... but without group membership. This is the RFC2307 schema. I think to fix you'd have to delete all IPA users and groups and re-migrate. > > The structure of Group in OpenLDAP is: > > # power, Group, ldapdomain.local > dn: cn=systems,ou=Group,dc=ldapdomain,dc=local > cn: systems > gidNumber: 1112 > objectClass: posixGroup > memberUid: usera > memberUid: userb > > > and IPA's schema appears, with one exception (objectClass: top), to match: > > # admins, groups, compat, ipadomain.local > dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local > objectClass: posixGroup > objectClass: top > gidNumber: 1944000000 > memberUid: admin > cn: admins That's the rfc 2307 compatibility view. If you look in cn=admins,cn=groups,cn=accounts,dc=ipadomain,dc=local you'll see how it is actually stored. > A side question: can i use migrate-ds to bring in automount and sudoer > maps from OpenLDAP? It's only users and groups right now. You might have some luck with automount importing via LDIF but at least the DN structure will need to be modified. You'd need to be pretty careful that the IPA schema matches your current schema. I think with sudo you'd be out of luck as IPA uses its own schema for storing the sudo components and rules. rob > > thanks again > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 | www.blue-bolt.com > > On 04/11/15 13:56, Rob Crittenden wrote: >> Cal Sawyer wrote: >>> Hi >>> >>> Very new to IPA and setting up a proof of concept system that i hope >>> will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to >>> import People, Group ou's into IPA using "ipa migrate-ds". The IPA and >>> existing LDAP directories have different BaseDNs (eg ipadomain.local on >>> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a >>> completely new directory that we will then switch our clients over to. >>> >>> ipa migrate-ds --schema=RFC2307 >>> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 >>> >>> whatever i try (w or w/o --schema=RFC2307) , the response is the same: >>> >>> ipa: ERROR: Insufficient access: Invalid credentials >>> >>> or with a verbose flag: >>> >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'https://ipa.ipadomain.local/ipa/session/xml' >>> ipa: ERROR: Insufficient access: Invalid credentials >>> >>> manager naturally exists in ldapdomain.local and i've definitely >>> supplied the correct password (we use the same creds to manage LDAP >>> using phpldapadmin) >>> >>> Hoping that someone has some experience with this and can point me in >>> the right direction? >> It is binding to openldap using cn=Directory Manager. If your admin user >> that can read userPassword is named something different then pass it in >> using the --binddn option. >> >> rob >> > From brian at interlinx.bc.ca Wed Nov 4 20:37:54 2015 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 04 Nov 2015 15:37:54 -0500 Subject: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts Message-ID: <1446669474.22705.126.camel@interlinx.bc.ca> I am trying to re-enroll clients after re-installing their O/S (EL6) using: # ipa-client-install --force-join ... Per http://www.freeipa.org/page/V3/Forced_client_re-enrollment but I am finding that after doing that for a given host, trying to ssh to it from another enrolled IPA client I am getting: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 15:db:4d:e2:8b:c2:b8:3d:da:93:90:06:f2:f1:d6:21. Please contact your system administrator. Add correct host key in /dev/null to get rid of this message. Offending DSA key in /var/lib/sss/pubconf/known_hosts:4 Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). Removing offending keys from /var/lib/sss/pubconf/known_hosts doesn't fix things as the offending key just gets put right back. Clearly something is going wrong with the re-enrollment and the SSH key of the new instance vs. the SSH key of the old instance. Am I doing something wrong or not doing something else I should be? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From Daryl.Fonseca-Holt at umanitoba.ca Wed Nov 4 22:34:16 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Wed, 4 Nov 2015 16:34:16 -0600 Subject: [Freeipa-users] ipa user-add slows down as more users are added Message-ID: <563A87E8.5090708@umanitoba.ca> Hi All, I am testing migration from NIS with a custom MySQL backend to IPA. In our testing ipa user-add starts out at around 12 seconds per user but slows down as more users are add. By 5000+ users it is taking 90+ seconds. We have 120,000+ users. I'm looking at 155 days to load all the users :( Per some performance tuning documentation I've increased nsslapd-cachememsize to 35,651,584 and am currently getting pretty high hit ratios (see below). However, one thread of ns-slapd pegs out core at 100% and I can't get get it to add users any faster. I'm not seeing any I/O or memory swapping. Suggestions would be appreciated. Multi-master will probably help but with that many accounts it would take a lot of masters to get additions done to a resonable (45 seconds or less?) time. Is there any guideline for number of users per master? # db_stat -h /var/lib/dirsrv/slapd-UOFMIDM/db -m 11MB 952KB Total cache size 1 Number of caches 1 Maximum number of caches 11MB 952KB Pool individual cache size 11MB 952KB Pool individual cache max 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 18M Requested pages found in the cache (97%) 382902 Requested pages not found in the cache 150 Pages created in the cache 382902 Pages read into the cache 11883 Pages written from the cache to the backing file 378331 Clean pages forced from the cache 4631 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 1481 Current total page count 1481 Current clean page count 0 Current dirty page count 2053 Number of hash buckets used for page location 2053 Number of mutexes for the hash buckets 4096 Assumed page size used 41M Total number of times hash chains searched for a page (41940301) 6 The longest hash chain searched for a page 0 Total number of hash chain entries checked for page 0 The number of hash bucket locks that required waiting (0%) 0 The maximum number of times any hash bucket lock was waited for (0%) 0 The number of region locks that required waiting (0%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 383400 The number of page allocations 1079845 The number of hash buckets examined during allocations 16 The maximum number of hash buckets examined for an allocation 1232650 The number of pages examined during allocations 14 The max number of pages examined for an allocation 0 Threads waited on page I/O 0 The number of times a sync is interrupted Pool File: ipaca/metaInfo.db 8192 Page size 0 Requested pages mapped into the process' address space 8 Requested pages found in the cache (80%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/serialno.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/gidnumber.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (9%) 47 Requested pages not found in the cache 0 Pages created in the cache 47 Pages read into the cache 45 Pages written from the cache to the backing file Pool File: userRoot/sn.db 8192 Page size 0 Requested pages mapped into the process' address space 97 Requested pages found in the cache (37%) 160 Requested pages not found in the cache 0 Pages created in the cache 160 Pages read into the cache 144 Pages written from the cache to the backing file Pool File: ipaca/requeststate.db 8192 Page size 0 Requested pages mapped into the process' address space 20 Requested pages found in the cache (86%) 3 Requested pages not found in the cache 0 Pages created in the cache 3 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/managedby.db 8192 Page size 0 Requested pages mapped into the process' address space 124 Requested pages found in the cache (96%) 4 Requested pages not found in the cache 0 Pages created in the cache 4 Pages read into the cache 2 Pages written from the cache to the backing file Pool File: changelog/ancestorid.db 8192 Page size 0 Requested pages mapped into the process' address space 75237 Requested pages found in the cache (99%) 81 Requested pages not found in the cache 0 Pages created in the cache 81 Pages read into the cache 259 Pages written from the cache to the backing file Pool File: ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 80 Requested pages found in the cache (91%) 7 Requested pages not found in the cache 0 Pages created in the cache 7 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/entryrdn.db 8192 Page size 0 Requested pages mapped into the process' address space 510 Requested pages found in the cache (95%) 23 Requested pages not found in the cache 0 Pages created in the cache 23 Pages read into the cache 2 Pages written from the cache to the backing file Pool File: changelog/entryusn.db 8192 Page size 0 Requested pages mapped into the process' address space 33741 Requested pages found in the cache (99%) 88 Requested pages not found in the cache 0 Pages created in the cache 88 Pages read into the cache 155 Pages written from the cache to the backing file Pool File: userRoot/mail.db 8192 Page size 0 Requested pages mapped into the process' address space 480 Requested pages found in the cache (36%) 841 Requested pages not found in the cache 0 Pages created in the cache 841 Pages read into the cache 825 Pages written from the cache to the backing file Pool File: userRoot/nsTombstoneCSN.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 4 Requested pages not found in the cache 0 Pages created in the cache 4 Pages read into the cache 3 Pages written from the cache to the backing file Pool File: changelog/parentid.db 8192 Page size 0 Requested pages mapped into the process' address space 75237 Requested pages found in the cache (99%) 81 Requested pages not found in the cache 0 Pages created in the cache 81 Pages read into the cache 259 Pages written from the cache to the backing file Pool File: ipaca/vlv#capendingpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 1 Requested pages not found in the cache 0 Pages created in the cache 1 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/vlv#cacompleteenrollmentpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: changelog/seeAlso.db 8192 Page size 0 Requested pages mapped into the process' address space 8 Requested pages found in the cache (80%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/memberOf.db 8192 Page size 0 Requested pages mapped into the process' address space 1501364 Requested pages found in the cache (99%) 713 Requested pages not found in the cache 0 Pages created in the cache 713 Pages read into the cache 45 Pages written from the cache to the backing file Pool File: changelog/numsubordinates.db 8192 Page size 0 Requested pages mapped into the process' address space 8572 Requested pages found in the cache (99%) 18 Requested pages not found in the cache 0 Pages created in the cache 18 Pages read into the cache 74 Pages written from the cache to the backing file Pool File: userRoot/parentid.db 8192 Page size 0 Requested pages mapped into the process' address space 3186 Requested pages found in the cache (90%) 333 Requested pages not found in the cache 0 Pages created in the cache 333 Pages read into the cache 47 Pages written from the cache to the backing file Pool File: ipaca/vlv#caallpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 26 Requested pages found in the cache (89%) 3 Requested pages not found in the cache 0 Pages created in the cache 3 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/member.db 8192 Page size 0 Requested pages mapped into the process' address space 2291464 Requested pages found in the cache (99%) 4231 Requested pages not found in the cache 0 Pages created in the cache 4231 Pages read into the cache 435 Pages written from the cache to the backing file Pool File: ipaca/duration.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/displayname.db 8192 Page size 0 Requested pages mapped into the process' address space 221 Requested pages found in the cache (52%) 201 Requested pages not found in the cache 1 Pages created in the cache 201 Pages read into the cache 187 Pages written from the cache to the backing file Pool File: userRoot/krbPrincipalName.db 8192 Page size 0 Requested pages mapped into the process' address space 2955 Requested pages found in the cache (81%) 652 Requested pages not found in the cache 0 Pages created in the cache 652 Pages read into the cache 518 Pages written from the cache to the backing file Pool File: userRoot/uidnumber.db 8192 Page size 0 Requested pages mapped into the process' address space 53 Requested pages found in the cache (41%) 76 Requested pages not found in the cache 0 Pages created in the cache 76 Pages read into the cache 15 Pages written from the cache to the backing file Pool File: userRoot/memberUser.db 8192 Page size 0 Requested pages mapped into the process' address space 8726 Requested pages found in the cache (99%) 33 Requested pages not found in the cache 0 Pages created in the cache 33 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: changelog/targetuniqueid.db 8192 Page size 0 Requested pages mapped into the process' address space 46518 Requested pages found in the cache (98%) 657 Requested pages not found in the cache 0 Pages created in the cache 657 Pages read into the cache 1107 Pages written from the cache to the backing file Pool File: userRoot/entryusn.db 8192 Page size 0 Requested pages mapped into the process' address space 2171 Requested pages found in the cache (98%) 40 Requested pages not found in the cache 0 Pages created in the cache 40 Pages read into the cache 73 Pages written from the cache to the backing file Pool File: ipaca/subjectname.db 8192 Page size 0 Requested pages mapped into the process' address space 207 Requested pages found in the cache (98%) 4 Requested pages not found in the cache 0 Pages created in the cache 4 Pages read into the cache 2 Pages written from the cache to the backing file Pool File: ipaca/numsubordinates.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/cn.db 8192 Page size 0 Requested pages mapped into the process' address space 327 Requested pages found in the cache (51%) 305 Requested pages not found in the cache 1 Pages created in the cache 305 Pages read into the cache 288 Pages written from the cache to the backing file Pool File: userRoot/nsuniqueid.db 8192 Page size 0 Requested pages mapped into the process' address space 313 Requested pages found in the cache (84%) 57 Requested pages not found in the cache 0 Pages created in the cache 57 Pages read into the cache 19 Pages written from the cache to the backing file Pool File: ipaca/vlv#caenrollmentpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 20 Requested pages found in the cache (90%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/notbefore.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/ipasudorunas.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/memberallowcmd.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/memberHost.db 8192 Page size 0 Requested pages mapped into the process' address space 8726 Requested pages found in the cache (99%) 33 Requested pages not found in the cache 0 Pages created in the cache 33 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: changelog/entryrdn.db 8192 Page size 0 Requested pages mapped into the process' address space 353202 Requested pages found in the cache (99%) 756 Requested pages not found in the cache 0 Pages created in the cache 756 Pages read into the cache 1097 Pages written from the cache to the backing file Pool File: ipaca/entryusn.db 8192 Page size 0 Requested pages mapped into the process' address space 145 Requested pages found in the cache (94%) 9 Requested pages not found in the cache 0 Pages created in the cache 9 Pages read into the cache 16 Pages written from the cache to the backing file Pool File: ipaca/vlv#capendingenrollmentpkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 1 Requested pages not found in the cache 0 Pages created in the cache 1 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/issuedby.db 8192 Page size 0 Requested pages mapped into the process' address space 2 Requested pages found in the cache (50%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/numsubordinates.db 8192 Page size 0 Requested pages mapped into the process' address space 9 Requested pages found in the cache (33%) 18 Requested pages not found in the cache 0 Pages created in the cache 18 Pages read into the cache 17 Pages written from the cache to the backing file Pool File: ipaca/seeAlso.db 8192 Page size 0 Requested pages mapped into the process' address space 17 Requested pages found in the cache (89%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: changelog/aci.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/vlv#allnonrevokedcertspkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/nsuniqueid.db 8192 Page size 0 Requested pages mapped into the process' address space 39 Requested pages found in the cache (90%) 4 Requested pages not found in the cache 0 Pages created in the cache 4 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/vlv#cacompletepkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/vlv#allvalidcertspkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/vlv#allinvalidcertspkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 1 Requested pages not found in the cache 0 Pages created in the cache 1 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/cn.db 8192 Page size 0 Requested pages mapped into the process' address space 46 Requested pages found in the cache (88%) 6 Requested pages not found in the cache 0 Pages created in the cache 6 Pages read into the cache 2 Pages written from the cache to the backing file Pool File: userRoot/seeAlso.db 8192 Page size 0 Requested pages mapped into the process' address space 9 Requested pages found in the cache (81%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/requesttype.db 8192 Page size 0 Requested pages mapped into the process' address space 20 Requested pages found in the cache (90%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/certstatus.db 8192 Page size 0 Requested pages mapped into the process' address space 20 Requested pages found in the cache (74%) 7 Requested pages not found in the cache 0 Pages created in the cache 7 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: /var/lib/dirsrv/slapd-UOFMIDM/cldb/20847805-823811e5-b80fb4f8-80522dbf_5638c652000000600000.db 8192 Page size 0 Requested pages mapped into the process' address space 51 Requested pages found in the cache (85%) 9 Requested pages not found in the cache 10 Pages created in the cache 9 Pages read into the cache 26 Pages written from the cache to the backing file Pool File: ipaca/objectclass.db 8192 Page size 0 Requested pages mapped into the process' address space 119 Requested pages found in the cache (90%) 12 Requested pages not found in the cache 0 Pages created in the cache 12 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: changelog/objectclass.db 8192 Page size 0 Requested pages mapped into the process' address space 238435 Requested pages found in the cache (99%) 206 Requested pages not found in the cache 0 Pages created in the cache 206 Pages read into the cache 631 Pages written from the cache to the backing file Pool File: ipaca/vlv#allinvalidcertsnotbeforepkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 34 Requested pages found in the cache (82%) 7 Requested pages not found in the cache 0 Pages created in the cache 7 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/uniquemember.db 8192 Page size 0 Requested pages mapped into the process' address space 739117 Requested pages found in the cache (99%) 53 Requested pages not found in the cache 0 Pages created in the cache 53 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/requestid.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/ipaassignedidview.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/memberservice.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/uid.db 8192 Page size 0 Requested pages mapped into the process' address space 168 Requested pages found in the cache (49%) 173 Requested pages not found in the cache 0 Pages created in the cache 173 Pages read into the cache 148 Pages written from the cache to the backing file Pool File: userRoot/id2entry.db 8192 Page size 0 Requested pages mapped into the process' address space 2083898 Requested pages found in the cache (85%) 366241 Requested pages not found in the cache 108 Pages created in the cache 366241 Pages read into the cache 1042 Pages written from the cache to the backing file Pool File: userRoot/givenName.db 8192 Page size 0 Requested pages mapped into the process' address space 106 Requested pages found in the cache (39%) 162 Requested pages not found in the cache 0 Pages created in the cache 162 Pages read into the cache 146 Pages written from the cache to the backing file Pool File: userRoot/ipauniqueid.db 8192 Page size 0 Requested pages mapped into the process' address space 31 Requested pages found in the cache (47%) 34 Requested pages not found in the cache 0 Pages created in the cache 34 Pages read into the cache 17 Pages written from the cache to the backing file Pool File: userRoot/sourcehost.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/manager.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: ipaca/description.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/ipatokenradiusconfiglink.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/owner.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: changelog/changenumber.db 8192 Page size 0 Requested pages mapped into the process' address space 64540 Requested pages found in the cache (99%) 89 Requested pages not found in the cache 0 Pages created in the cache 89 Pages read into the cache 151 Pages written from the cache to the backing file Pool File: userRoot/macAddress.db 8192 Page size 0 Requested pages mapped into the process' address space 4 Requested pages found in the cache (57%) 3 Requested pages not found in the cache 0 Pages created in the cache 3 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/entryrdn.db 8192 Page size 0 Requested pages mapped into the process' address space 5394336 Requested pages found in the cache (99%) 1967 Requested pages not found in the cache 1 Pages created in the cache 1967 Pages read into the cache 90 Pages written from the cache to the backing file Pool File: userRoot/fqdn.db 8192 Page size 0 Requested pages mapped into the process' address space 1 Requested pages found in the cache (25%) 3 Requested pages not found in the cache 0 Pages created in the cache 3 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/ancestorid.db 8192 Page size 0 Requested pages mapped into the process' address space 17 Requested pages found in the cache (89%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/parentid.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: ipaca/dateOfCreate.db 8192 Page size 0 Requested pages mapped into the process' address space 11 Requested pages found in the cache (84%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: /var/lib/dirsrv/slapd-UOFMIDM/cldb/2f771606-81b711e5-b80fb4f8-80522dbf_5637ee05000000040000.db 8192 Page size 0 Requested pages mapped into the process' address space 601 Requested pages found in the cache (89%) 73 Requested pages not found in the cache 20 Pages created in the cache 73 Pages read into the cache 124 Pages written from the cache to the backing file Pool File: ipaca/vlv#allcertspkitomcatindex.db 8192 Page size 0 Requested pages mapped into the process' address space 11 Requested pages found in the cache (78%) 3 Requested pages not found in the cache 0 Pages created in the cache 3 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: changelog/id2entry.db 8192 Page size 0 Requested pages mapped into the process' address space 98124 Requested pages found in the cache (97%) 2042 Requested pages not found in the cache 0 Pages created in the cache 2042 Pages read into the cache 2203 Pages written from the cache to the backing file Pool File: ipaca/notafter.db 8192 Page size 0 Requested pages mapped into the process' address space 5 Requested pages found in the cache (71%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/nscpEntryDN.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 4 Requested pages not found in the cache 0 Pages created in the cache 4 Pages read into the cache 3 Pages written from the cache to the backing file Pool File: userRoot/ipakrbprincipalalias.db 8192 Page size 0 Requested pages mapped into the process' address space 813 Requested pages found in the cache (95%) 38 Requested pages not found in the cache 0 Pages created in the cache 38 Pages read into the cache 2 Pages written from the cache to the backing file Pool File: userRoot/ancestorid.db 8192 Page size 0 Requested pages mapped into the process' address space 982 Requested pages found in the cache (81%) 220 Requested pages not found in the cache 0 Pages created in the cache 220 Pages read into the cache 115 Pages written from the cache to the backing file Pool File: ipaca/id2entry.db 8192 Page size 0 Requested pages mapped into the process' address space 216 Requested pages found in the cache (77%) 62 Requested pages not found in the cache 9 Pages created in the cache 62 Pages read into the cache 69 Pages written from the cache to the backing file Pool File: ipaca/extension.db 8192 Page size 0 Requested pages mapped into the process' address space 410 Requested pages found in the cache (98%) 5 Requested pages not found in the cache 0 Pages created in the cache 5 Pages read into the cache 3 Pages written from the cache to the backing file Pool File: userRoot/memberdenycmd.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/secretary.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/aci.db 8192 Page size 0 Requested pages mapped into the process' address space 1 Requested pages found in the cache (33%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: userRoot/objectclass.db 8192 Page size 0 Requested pages mapped into the process' address space 4643721 Requested pages found in the cache (99%) 1137 Requested pages not found in the cache 0 Pages created in the cache 1137 Pages read into the cache 456 Pages written from the cache to the backing file Pool File: ipaca/publicKeyData.db 8192 Page size 0 Requested pages mapped into the process' address space 2 Requested pages found in the cache (50%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 1 Pages written from the cache to the backing file Pool File: userRoot/ipasudorunasgroup.db 8192 Page size 0 Requested pages mapped into the process' address space 0 Requested pages found in the cache (0%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: changelog/nsuniqueid.db 8192 Page size 0 Requested pages mapped into the process' address space 42626 Requested pages found in the cache (98%) 787 Requested pages not found in the cache 0 Pages created in the cache 787 Pages read into the cache 994 Pages written from the cache to the backing file Pool File: ipaca/aci.db 8192 Page size 0 Requested pages mapped into the process' address space 1 Requested pages found in the cache (33%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Thanks, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From rcritten at redhat.com Wed Nov 4 23:07:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 18:07:18 -0500 Subject: [Freeipa-users] ipa user-add slows down as more users are added In-Reply-To: <563A87E8.5090708@umanitoba.ca> References: <563A87E8.5090708@umanitoba.ca> Message-ID: <563A8FA6.5080203@redhat.com> Daryl Fonseca-Holt wrote: > Hi All, > > I am testing migration from NIS with a custom MySQL backend to IPA. In > our testing ipa user-add starts out at around 12 seconds per user but > slows down as more users are add. By 5000+ users it is taking 90+ > seconds. We have 120,000+ users. I'm looking at 155 days to load all the > users :( > > Per some performance tuning documentation I've increased > nsslapd-cachememsize to 35,651,584 and am currently getting pretty high > hit ratios (see below). However, one thread of ns-slapd pegs out core at > 100% and I can't get get it to add users any faster. I'm not seeing any > I/O or memory swapping. The problem is most likely the default IPA users group. As it gets humongous adding new members slows it down. > Suggestions would be appreciated. Multi-master will probably help but > with that many accounts it would take a lot of masters to get additions > done to a resonable (45 seconds or less?) time. Is there any guideline > for number of users per master? IPA is multi-master. All users are on all masters. If anything I'd expect that running imports on different masters would slow things down as changes on multiple masters would need to get merged together, particularly the default group. Certainly bumping up the caches to match what the final expected sizes is probably a good idea but I don't see it influencing import speed all that much. One idea I've had is to add the users in batches of 1000. What you'd do is create 120 non-POSIX user groups, ipausers1..ipausers120, and add them as members of ipausers. Then for each batch change the default ipausers group with: $ ipa config-mod --defaultgroup= This should keep the user-add command fairly peppy and keep the ipausers group somewhat in check via the nesting. I imagine that the UI would blow up if you tried to view the ipausers group as it tried to dereference 120k users. You'll probably also want to disable the compat module for the import. I assume you've already done some amount of testing with a smaller batch of users to ensure they migrate ok, passwords work, etc? rob From rmeggins at redhat.com Wed Nov 4 23:25:12 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 4 Nov 2015 16:25:12 -0700 Subject: [Freeipa-users] ipa user-add slows down as more users are added In-Reply-To: <563A8FA6.5080203@redhat.com> References: <563A87E8.5090708@umanitoba.ca> <563A8FA6.5080203@redhat.com> Message-ID: <563A93D8.1090805@redhat.com> On 11/04/2015 04:07 PM, Rob Crittenden wrote: > Daryl Fonseca-Holt wrote: >> Hi All, >> >> I am testing migration from NIS with a custom MySQL backend to IPA. In >> our testing ipa user-add starts out at around 12 seconds per user but >> slows down as more users are add. By 5000+ users it is taking 90+ >> seconds. We have 120,000+ users. I'm looking at 155 days to load all the >> users :( >> >> Per some performance tuning documentation I've increased >> nsslapd-cachememsize to 35,651,584 and am currently getting pretty high >> hit ratios (see below). Use dbmon.sh instead of db_stat - it will give you the entry cache information as well as a summary of the db cache information (instead of the quite verbose db_stat output). >> However, one thread of ns-slapd pegs out core at >> 100% and I can't get get it to add users any faster. I'm not seeing any >> I/O or memory swapping. > The problem is most likely the default IPA users group. As it gets > humongous adding new members slows it down. So could he disable the automember and memberof plugins? Then have those work offline, after the users are added? > >> Suggestions would be appreciated. Multi-master will probably help but >> with that many accounts it would take a lot of masters to get additions >> done to a resonable (45 seconds or less?) time. Is there any guideline >> for number of users per master? > IPA is multi-master. All users are on all masters. > > If anything I'd expect that running imports on different masters would > slow things down as changes on multiple masters would need to get merged > together, particularly the default group. Right. > > Certainly bumping up the caches to match what the final expected sizes > is probably a good idea but I don't see it influencing import speed all > that much. Right. > > One idea I've had is to add the users in batches of 1000. What you'd do > is create 120 non-POSIX user groups, ipausers1..ipausers120, and add > them as members of ipausers. > > Then for each batch change the default ipausers group with: > > $ ipa config-mod --defaultgroup= > > This should keep the user-add command fairly peppy and keep the ipausers > group somewhat in check via the nesting. > > I imagine that the UI would blow up if you tried to view the ipausers > group as it tried to dereference 120k users. > > You'll probably also want to disable the compat module for the import. > > I assume you've already done some amount of testing with a smaller batch > of users to ensure they migrate ok, passwords work, etc? > > rob > From prasun.gera at gmail.com Wed Nov 4 23:20:22 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 4 Nov 2015 15:20:22 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl Message-ID: I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. I'm using a stock configuration which uses the certs signed by ipa's CA for the webui. This is mostly for convenience since it manages renewals seamlessly. This, however, requires users to add the CA as trusted to their browsers. A promising alternative to this is https://letsencrypt.org/, which issues browser trusted certs, and will manage auto renewals too (in the future). As a feature request, it would be nice to have closer integration between ipa and the letsencrypt client which would make managing certs simple. I'm about to set this up manually right now using the external ssl certs guide. Secondly, since the webui uses mod_nss, how would one set it up to prefer security over compatibility with older clients ? The vast majority of documentation online (for eg. https://mozilla.github.io/server-side-tls/ssl-config-generator/) is about mod_ssl and I think the configuration doesn't transfer directly to mod_nss. Since this is the only web facing component, I would like to set it up to use stringent requirements. Right now, a test on https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html identifies several issues. Since these things are not really my area of expertise, I would like some documentation regarding this. Also, would manually modifying any of the config files be overwritten by a yum update ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Nov 5 00:44:59 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 Nov 2015 10:44:59 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: Message-ID: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. I'm > using a stock configuration which uses the certs signed by ipa's CA for the > webui. This is mostly for convenience since it manages renewals seamlessly. > This, however, requires users to add the CA as trusted to their browsers. A > promising alternative to this is https://letsencrypt.org/, which issues > browser trusted certs, and will manage auto renewals too (in the future). > As a feature request, it would be nice to have closer integration between > ipa and the letsencrypt client which would make managing certs simple. I'm > about to set this up manually right now using the external ssl certs guide. > Let's Encrypt is on our radar. I like the idea of being able to install FreeIPA with publicly-trusted certs for HTTP and LDAP from the beginning. This would require some work in ipa-server-install in addition to certmonger support and a good, stable Let's Encrypt / ACME client implementation for Apache on Fedora. Installing publicly-trusted HTTP / LDAP certs is a common activity so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 Cheers, Fraser > Secondly, since the webui uses mod_nss, how would one set it up to prefer > security over compatibility with older clients ? The vast majority of > documentation online (for eg. > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is about > mod_ssl and I think the configuration doesn't transfer directly to mod_nss. > Since this is the only web facing component, I would like to set it up to > use stringent requirements. Right now, a test on > https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html > identifies > several issues. Since these things are not really my area of expertise, I > would like some documentation regarding this. Also, would manually > modifying any of the config files be overwritten by a yum update ? > -- > 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 From prashant at apigee.com Thu Nov 5 01:01:33 2015 From: prashant at apigee.com (Prashant Bapat) Date: Thu, 5 Nov 2015 06:31:33 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: <563A0C83.3040402@redhat.com> References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> <5639D099.5020104@redhat.com> <563A0C83.3040402@redhat.com> Message-ID: Great idea! Is that possible ? Any documentation on how to do this would be very helpful. Thanks. On 4 November 2015 at 19:17, Rob Crittenden wrote: > Martin Kosek wrote: > > On 11/04/2015 10:27 AM, Prashant Bapat wrote: > >> Ack. But in a live replicated setup wont upgrading from F21->F22 and > >> F22->F23 take a long time. I mean couple of hours ? > > > > It will take some outage time, yes. But if you have appropriate number of > > replicas and are upgrading one by one, you should be fine - the clients > should > > fail over to other replicas. > > > >> Are there any other ways to do this. Perhaps do a fresh install of F23 > and > >> then restore data from FreeIPA 4.1.4 (F21) ? > > > > FreeIPA upgrade also updates the data themselves. Restoring old data and > > configuration files on fresh F23 using full backup + running the upgrade > may > > work, but there may be also a lot of hurdles. It is not really a tested > approach. > > Or he could one by one install a new F23 system and configure it as a > new master to replace one of the old ones until they are all running F23. > > I'm pretty sure backup/restore only works within the same version. > > rob > > > > >> > >> On 4 November 2015 at 14:52, Martin Kosek wrote: > >> > >>> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: > >>>> On (04/11/15 14:37), Prashant Bapat wrote: > >>>>> Hi All, > >>>>> > >>>>> We rolled out freeipa in our setup somewhere in beginning of 2015. > Since > >>>>> then there have been couple of new releases. Latest being 4.2.3. > >>>>> > >>>>> The FreeIPA servers are installed on Fedora 21 hosts and at this > point > >>>>> there is no direct way of upgrading to 4.2.3 unless we also upgrade > the > >>> OS. > >>>>> The COPR repos do not support Fedora 21. > >>>>> > >>>> Fedora 23 was released yesterday. > >>>> It means then Fedora 21 will be out of support in a month. > >>>> I would definitelly recomment to upgrade it to newer Fedora. > >>> > >>> +1. I did the same actually for FreeIPA demo which was also running on > F21 > >>> before: > >>> http://www.freeipa.org/page/Demo > >>> I had to do it in two steps: F21->F22, F22->F23. > >>> > >>> If you make sure that F22->F23 upgrade updates to freeipa-4.2.3-1.fc23 > or > >>> later > >>> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it > >>> should > >>> work just fine. > >>> > >>>> If you do not want t upgrade so often you might use FreeIPA > >>>> on CentOS 7 > >>>> > >>>> LS > >>>> > >>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Nov 5 01:03:29 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 4 Nov 2015 17:03:29 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> Message-ID: Thanks for the ticket information. I would still be interested in configuring mod_nss properly (irrespective of whether the certs are ipa generated or 3rd party). These are the worrying notes from ssllabs test: The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C. This server accepts the RC4 cipher, which is weak. Grade capped to B. The server does not support Forward Secrecy with the reference browsers. On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale wrote: > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. > I'm > > using a stock configuration which uses the certs signed by ipa's CA for > the > > webui. This is mostly for convenience since it manages renewals > seamlessly. > > This, however, requires users to add the CA as trusted to their > browsers. A > > promising alternative to this is https://letsencrypt.org/, which issues > > browser trusted certs, and will manage auto renewals too (in the future). > > As a feature request, it would be nice to have closer integration between > > ipa and the letsencrypt client which would make managing certs simple. > I'm > > about to set this up manually right now using the external ssl certs > guide. > > > Let's Encrypt is on our radar. I like the idea of being able to > install FreeIPA with publicly-trusted certs for HTTP and LDAP from > the beginning. This would require some work in ipa-server-install > in addition to certmonger support and a good, stable Let's Encrypt / > ACME client implementation for Apache on Fedora. > > Installing publicly-trusted HTTP / LDAP certs is a common activity > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 > > Cheers, > Fraser > > > Secondly, since the webui uses mod_nss, how would one set it up to prefer > > security over compatibility with older clients ? The vast majority of > > documentation online (for eg. > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > about > > mod_ssl and I think the configuration doesn't transfer directly to > mod_nss. > > Since this is the only web facing component, I would like to set it up to > > use stringent requirements. Right now, a test on > > https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html > > identifies > > several issues. Since these things are not really my area of expertise, I > > would like some documentation regarding this. Also, would manually > > modifying any of the config files be overwritten by a yum update ? > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 5 03:22:21 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Nov 2015 22:22:21 -0500 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> Message-ID: <563ACB6D.8000106@redhat.com> Prasun Gera wrote: > Thanks for the ticket information. I would still be interested in > configuring mod_nss properly (irrespective of whether the certs are ipa > generated or 3rd party). These are the worrying notes from ssllabs test: > > The server supports only older protocols, but not the current best TLS > 1.2. Grade capped to C. TLSv1.2 support in mod_nss will be available in RHEL 7.2. The version of mod_nss in 7.1 only supports up to v1.1. > This server accepts the RC4 cipher, which is weak. Grade capped to B. You'll need to manually set your own cipher list excluding RC4 ciphers. It depends on how compatible you want to be with older clients, but perhaps something like this: NSSCipherSuite +rsa_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,+ecdhe_rsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_3des_sha > The server does not support Forward Secrecy with the reference browsers. This will go away when you enable the ECDHE ciphers. Changes to this file should survive upgrades. rob > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > wrote: > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. I'm > > using a stock configuration which uses the certs signed by ipa's CA for the > > webui. This is mostly for convenience since it manages renewals seamlessly. > > This, however, requires users to add the CA as trusted to their browsers. A > > promising alternative to this is https://letsencrypt.org/, which issues > > browser trusted certs, and will manage auto renewals too (in the future). > > As a feature request, it would be nice to have closer integration between > > ipa and the letsencrypt client which would make managing certs simple. I'm > > about to set this up manually right now using the external ssl certs guide. > > > Let's Encrypt is on our radar. I like the idea of being able to > install FreeIPA with publicly-trusted certs for HTTP and LDAP from > the beginning. This would require some work in ipa-server-install > in addition to certmonger support and a good, stable Let's Encrypt / > ACME client implementation for Apache on Fedora. > > Installing publicly-trusted HTTP / LDAP certs is a common activity > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 > > Cheers, > Fraser > > > Secondly, since the webui uses mod_nss, how would one set it up to > prefer > > security over compatibility with older clients ? The vast majority of > > documentation online (for eg. > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > is about > > mod_ssl and I think the configuration doesn't transfer directly to > mod_nss. > > Since this is the only web facing component, I would like to set > it up to > > use stringent requirements. Right now, a test on > > https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html > > identifies > > several issues. Since these things are not really my area of > expertise, I > > would like some documentation regarding this. Also, would manually > > modifying any of the config files be overwritten by a yum update ? > > > -- > > 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 > > > > From ftweedal at redhat.com Thu Nov 5 04:21:22 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 Nov 2015 14:21:22 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> Message-ID: <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > Thanks for the ticket information. I would still be interested in > configuring mod_nss properly (irrespective of whether the certs are ipa > generated or 3rd party). These are the worrying notes from ssllabs test: > > The server supports only older protocols, but not the current best TLS 1.2. > Grade capped to C. > This server accepts the RC4 cipher, which is weak. Grade capped to B. > The server does not support Forward Secrecy with the reference browsers. > Use the "Modern" cipher suite[1] recommended by Mozilla as a starting point. See also the "Cipher names correspondence table" on the same page for translating it to cipher names understood by NSS to construct a valid setting for the `NSSCipherSuite' directive. [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility Cheers, Fraser > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale wrote: > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. > > I'm > > > using a stock configuration which uses the certs signed by ipa's CA for > > the > > > webui. This is mostly for convenience since it manages renewals > > seamlessly. > > > This, however, requires users to add the CA as trusted to their > > browsers. A > > > promising alternative to this is https://letsencrypt.org/, which issues > > > browser trusted certs, and will manage auto renewals too (in the future). > > > As a feature request, it would be nice to have closer integration between > > > ipa and the letsencrypt client which would make managing certs simple. > > I'm > > > about to set this up manually right now using the external ssl certs > > guide. > > > > > Let's Encrypt is on our radar. I like the idea of being able to > > install FreeIPA with publicly-trusted certs for HTTP and LDAP from > > the beginning. This would require some work in ipa-server-install > > in addition to certmonger support and a good, stable Let's Encrypt / > > ACME client implementation for Apache on Fedora. > > > > Installing publicly-trusted HTTP / LDAP certs is a common activity > > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 > > > > Cheers, > > Fraser > > > > > Secondly, since the webui uses mod_nss, how would one set it up to prefer > > > security over compatibility with older clients ? The vast majority of > > > documentation online (for eg. > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > about > > > mod_ssl and I think the configuration doesn't transfer directly to > > mod_nss. > > > Since this is the only web facing component, I would like to set it up to > > > use stringent requirements. Right now, a test on > > > https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html > > > identifies > > > several issues. Since these things are not really my area of expertise, I > > > would like some documentation regarding this. Also, would manually > > > modifying any of the config files be overwritten by a yum update ? > > > > > -- > > > 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 > > > > From prashant at apigee.com Thu Nov 5 06:02:54 2015 From: prashant at apigee.com (Prashant Bapat) Date: Thu, 5 Nov 2015 11:32:54 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> <5639D099.5020104@redhat.com> <563A0C83.3040402@redhat.com> Message-ID: New issue with upgrade. I setup a test IPA server. Its on AWS EC2 instance in a VPC. Fedora 21. freeipa 4.1.4. Upgraded OS from F21 --> F22 --> F23. All OK. Once in F23 *ipactl start* command tells me an upgrade is needed. Ran* ipa-server-upgrade* command. This command seems to do everything but somehow fails during upgrading the PKI (Tomcat). Now the tomcat service wont start. Other components are upgraded to 4.2.2 but Tomcat is down. Attached is the *ipaupgrade.log* and *catalina.2015-11-05.log*. Any help appreciated. Thanks. --Prashant On 5 November 2015 at 06:31, Prashant Bapat wrote: > Great idea! Is that possible ? Any documentation on how to do this would > be very helpful. > > Thanks. > > On 4 November 2015 at 19:17, Rob Crittenden wrote: > >> Martin Kosek wrote: >> > On 11/04/2015 10:27 AM, Prashant Bapat wrote: >> >> Ack. But in a live replicated setup wont upgrading from F21->F22 and >> >> F22->F23 take a long time. I mean couple of hours ? >> > >> > It will take some outage time, yes. But if you have appropriate number >> of >> > replicas and are upgrading one by one, you should be fine - the clients >> should >> > fail over to other replicas. >> > >> >> Are there any other ways to do this. Perhaps do a fresh install of F23 >> and >> >> then restore data from FreeIPA 4.1.4 (F21) ? >> > >> > FreeIPA upgrade also updates the data themselves. Restoring old data and >> > configuration files on fresh F23 using full backup + running the >> upgrade may >> > work, but there may be also a lot of hurdles. It is not really a tested >> approach. >> >> Or he could one by one install a new F23 system and configure it as a >> new master to replace one of the old ones until they are all running F23. >> >> I'm pretty sure backup/restore only works within the same version. >> >> rob >> >> > >> >> >> >> On 4 November 2015 at 14:52, Martin Kosek wrote: >> >> >> >>> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: >> >>>> On (04/11/15 14:37), Prashant Bapat wrote: >> >>>>> Hi All, >> >>>>> >> >>>>> We rolled out freeipa in our setup somewhere in beginning of 2015. >> Since >> >>>>> then there have been couple of new releases. Latest being 4.2.3. >> >>>>> >> >>>>> The FreeIPA servers are installed on Fedora 21 hosts and at this >> point >> >>>>> there is no direct way of upgrading to 4.2.3 unless we also upgrade >> the >> >>> OS. >> >>>>> The COPR repos do not support Fedora 21. >> >>>>> >> >>>> Fedora 23 was released yesterday. >> >>>> It means then Fedora 21 will be out of support in a month. >> >>>> I would definitelly recomment to upgrade it to newer Fedora. >> >>> >> >>> +1. I did the same actually for FreeIPA demo which was also running >> on F21 >> >>> before: >> >>> http://www.freeipa.org/page/Demo >> >>> I had to do it in two steps: F21->F22, F22->F23. >> >>> >> >>> If you make sure that F22->F23 upgrade updates to >> freeipa-4.2.3-1.fc23 or >> >>> later >> >>> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it >> >>> should >> >>> work just fine. >> >>> >> >>>> If you do not want t upgrade so often you might use FreeIPA >> >>>> on CentOS 7 >> >>>> >> >>>> LS >> >>>> >> >>> >> >>> >> >> >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-upgrade-error.zip Type: application/zip Size: 172687 bytes Desc: not available URL: From prashant at apigee.com Thu Nov 5 07:28:28 2015 From: prashant at apigee.com (Prashant Bapat) Date: Thu, 5 Nov 2015 12:58:28 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> <5639D099.5020104@redhat.com> <563A0C83.3040402@redhat.com> Message-ID: Looks like there are issues with dogtag and tomcat8. http://pki.fedoraproject.org/wiki/Tomcat_8 On 5 November 2015 at 11:32, Prashant Bapat wrote: > New issue with upgrade. > > I setup a test IPA server. Its on AWS EC2 instance in a VPC. Fedora 21. > freeipa 4.1.4. > > Upgraded OS from F21 --> F22 --> F23. All OK. > > Once in F23 *ipactl start* command tells me an upgrade is needed. > > Ran* ipa-server-upgrade* command. This command seems to do everything but > somehow fails during upgrading the PKI (Tomcat). Now the tomcat service > wont start. Other components are upgraded to 4.2.2 but Tomcat is down. > > Attached is the *ipaupgrade.log* and *catalina.2015-11-05.log*. > > Any help appreciated. > > Thanks. > --Prashant > > On 5 November 2015 at 06:31, Prashant Bapat wrote: > >> Great idea! Is that possible ? Any documentation on how to do this would >> be very helpful. >> >> Thanks. >> >> On 4 November 2015 at 19:17, Rob Crittenden wrote: >> >>> Martin Kosek wrote: >>> > On 11/04/2015 10:27 AM, Prashant Bapat wrote: >>> >> Ack. But in a live replicated setup wont upgrading from F21->F22 and >>> >> F22->F23 take a long time. I mean couple of hours ? >>> > >>> > It will take some outage time, yes. But if you have appropriate number >>> of >>> > replicas and are upgrading one by one, you should be fine - the >>> clients should >>> > fail over to other replicas. >>> > >>> >> Are there any other ways to do this. Perhaps do a fresh install of >>> F23 and >>> >> then restore data from FreeIPA 4.1.4 (F21) ? >>> > >>> > FreeIPA upgrade also updates the data themselves. Restoring old data >>> and >>> > configuration files on fresh F23 using full backup + running the >>> upgrade may >>> > work, but there may be also a lot of hurdles. It is not really a >>> tested approach. >>> >>> Or he could one by one install a new F23 system and configure it as a >>> new master to replace one of the old ones until they are all running F23. >>> >>> I'm pretty sure backup/restore only works within the same version. >>> >>> rob >>> >>> > >>> >> >>> >> On 4 November 2015 at 14:52, Martin Kosek wrote: >>> >> >>> >>> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: >>> >>>> On (04/11/15 14:37), Prashant Bapat wrote: >>> >>>>> Hi All, >>> >>>>> >>> >>>>> We rolled out freeipa in our setup somewhere in beginning of 2015. >>> Since >>> >>>>> then there have been couple of new releases. Latest being 4.2.3. >>> >>>>> >>> >>>>> The FreeIPA servers are installed on Fedora 21 hosts and at this >>> point >>> >>>>> there is no direct way of upgrading to 4.2.3 unless we also >>> upgrade the >>> >>> OS. >>> >>>>> The COPR repos do not support Fedora 21. >>> >>>>> >>> >>>> Fedora 23 was released yesterday. >>> >>>> It means then Fedora 21 will be out of support in a month. >>> >>>> I would definitelly recomment to upgrade it to newer Fedora. >>> >>> >>> >>> +1. I did the same actually for FreeIPA demo which was also running >>> on F21 >>> >>> before: >>> >>> http://www.freeipa.org/page/Demo >>> >>> I had to do it in two steps: F21->F22, F22->F23. >>> >>> >>> >>> If you make sure that F22->F23 upgrade updates to >>> freeipa-4.2.3-1.fc23 or >>> >>> later >>> >>> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), it >>> >>> should >>> >>> work just fine. >>> >>> >>> >>>> If you do not want t upgrade so often you might use FreeIPA >>> >>>> on CentOS 7 >>> >>>> >>> >>>> LS >>> >>>> >>> >>> >>> >>> >>> >> >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Nov 5 05:34:02 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 4 Nov 2015 21:34:02 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> Message-ID: Yes, that's what I was planning to do. i.e. Convert cipher names from SSL to NSS. I wasn't sure about the other settings though. Is there an equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there equivalent configs for HSTS on the mozilla page? Does NSS allow using generated DH parameters instead of standard ones ? For SSL, the suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"' after generating the params. On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale wrote: > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > Thanks for the ticket information. I would still be interested in > > configuring mod_nss properly (irrespective of whether the certs are ipa > > generated or 3rd party). These are the worrying notes from ssllabs test: > > > > The server supports only older protocols, but not the current best TLS > 1.2. > > Grade capped to C. > > This server accepts the RC4 cipher, which is weak. Grade capped to B. > > The server does not support Forward Secrecy with the reference browsers. > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > starting point. See also the "Cipher names correspondence table" on > the same page for translating it to cipher names understood by NSS > to construct a valid setting for the `NSSCipherSuite' directive. > > [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > Cheers, > Fraser > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > wrote: > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible > publicly. > > > I'm > > > > using a stock configuration which uses the certs signed by ipa's CA > for > > > the > > > > webui. This is mostly for convenience since it manages renewals > > > seamlessly. > > > > This, however, requires users to add the CA as trusted to their > > > browsers. A > > > > promising alternative to this is https://letsencrypt.org/, which > issues > > > > browser trusted certs, and will manage auto renewals too (in the > future). > > > > As a feature request, it would be nice to have closer integration > between > > > > ipa and the letsencrypt client which would make managing certs > simple. > > > I'm > > > > about to set this up manually right now using the external ssl certs > > > guide. > > > > > > > Let's Encrypt is on our radar. I like the idea of being able to > > > install FreeIPA with publicly-trusted certs for HTTP and LDAP from > > > the beginning. This would require some work in ipa-server-install > > > in addition to certmonger support and a good, stable Let's Encrypt / > > > ACME client implementation for Apache on Fedora. > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common activity > > > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 > > > > > > Cheers, > > > Fraser > > > > > > > Secondly, since the webui uses mod_nss, how would one set it up to > prefer > > > > security over compatibility with older clients ? The vast majority of > > > > documentation online (for eg. > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > > about > > > > mod_ssl and I think the configuration doesn't transfer directly to > > > mod_nss. > > > > Since this is the only web facing component, I would like to set it > up to > > > > use stringent requirements. Right now, a test on > > > > https://www.ssllabs.com/ssltest/ and > https://weakdh.org/sysadmin.html > > > > identifies > > > > several issues. Since these things are not really my area of > expertise, I > > > > would like some documentation regarding this. Also, would manually > > > > modifying any of the config files be overwritten by a yum update ? > > > > > > > -- > > > > 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 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Thu Nov 5 08:33:48 2015 From: th at casalogic.dk (Troels Hansen) Date: Thu, 5 Nov 2015 09:33:48 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151104150346.GC3586@p.redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> <688888716.8428825.1446647689417.JavaMail.zimbra@casalogic.dk> <20151104150346.GC3586@p.redhat.com> Message-ID: <1715675829.8575280.1446712428650.JavaMail.zimbra@casalogic.dk> ----- On Nov 4, 2015, at 4:03 PM, Sumit Bose sbose at redhat.com wrote: > > do you see any more details if you run pdbedit with '-d 255' ? > Not really: pdbedit -d 255 -Lv th ........... check lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: Locking key 534543524554532F5349442F434153414C4F4749432E4C414E Allocated locked data 0x0x7f8d46d0cb40 Unlocking key 534543524554532F5349442F434153414C4F4749432E4C414E release lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1: 2: 3: check lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: Locking key 534543524554532F5349442F434153414C4F474943 Allocated locked data 0x0x7f8d46d0ccc0 Unlocking key 534543524554532F5349442F434153414C4F474943 release lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1: 2: 3: check lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: Locking key 534543524554532F5349442F4B454E4149 Allocated locked data 0x0x7f8d46d0d1c0 Unlocking key 534543524554532F5349442F4B454E4149 release lock order 1 for /var/lib/samba/private/secrets.tdb lock order: 1: 2: 3: smbldap_search_ext: base => [cn=CASALOGIC.LAN,cn=kerberos,dc=casalogic,dc=lan], filter => [objectclass=krbrealmcontainer], scope => [0] smbldap_open: already connected to the LDAP server Attribute [krbDefaultEncSaltTypes] not found. pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-CASALOGIC-LAN.socket has a valid init smbldap_search_ext: base => [dc=casalogic,dc=lan], filter => [(&(objectClass=ipaNTUserAttrs)(uid=th))], scope => [2] smbldap_open: already connected to the LDAP server init_sam_from_ldap: Entry found for user: th pdb_set_username: setting username th, was element 11 -> now SET pdb_set_domain: setting domain casalogic.lan, was element 13 -> now DEFAULT pdb_set_nt_username: setting nt username th, was element 14 -> now SET pdb_set_user_sid_from_string: setting user sid S-1-5-21-3663793457-3789003531-2001508300-2004 pdb_set_user_sid: setting user sid S-1-5-21-3663793457-3789003531-2001508300-2004 element 17 -> now SET Segmentation fault [root at kenai ~]# > > Can you send me a full backtrace of the core or the whole core file with > the version of the samba.common package? > I have captured a coredump with abrt. Should I just send it directly to you? (20Mb uncompressed). From natxo.asenjo at gmail.com Thu Nov 5 09:03:58 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Nov 2015 10:03:58 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work Message-ID: hi, since yesterday I have a strange situation in one of our joined hosts. i can login using a kerberos ticket, but not using name/password. In /var/log/secure I see this: sshd[29607]: pam_sss(sshd:auth): received for user username: 4 (System error) -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Nov 5 09:04:47 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 5 Nov 2015 10:04:47 +0100 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1715675829.8575280.1446712428650.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> <20151030141953.GU8374@redhat.com> <1038568425.8179964.1446552593834.JavaMail.zimbra@casalogic.dk> <20151103123604.GD22483@p.redhat.com> <827457322.8246660.1446577609664.JavaMail.zimbra@casalogic.dk> <688888716.8428825.1446647689417.JavaMail.zimbra@casalogic.dk> <20151104150346.GC3586@p.redhat.com> <1715675829.8575280.1446712428650.JavaMail.zimbra@casalogic.dk> Message-ID: <20151105090447.GH3586@p.redhat.com> On Thu, Nov 05, 2015 at 09:33:48AM +0100, Troels Hansen wrote: > > ----- On Nov 4, 2015, at 4:03 PM, Sumit Bose sbose at redhat.com wrote: > > > > > do you see any more details if you run pdbedit with '-d 255' ? > > > > Not really: > > pdbedit -d 255 -Lv th > ........... > check lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: > Locking key 534543524554532F5349442F434153414C4F4749432E4C414E > Allocated locked data 0x0x7f8d46d0cb40 > Unlocking key 534543524554532F5349442F434153414C4F4749432E4C414E > release lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1: 2: 3: > check lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: > Locking key 534543524554532F5349442F434153414C4F474943 > Allocated locked data 0x0x7f8d46d0ccc0 > Unlocking key 534543524554532F5349442F434153414C4F474943 > release lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1: 2: 3: > check lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1:/var/lib/samba/private/secrets.tdb 2: 3: > Locking key 534543524554532F5349442F4B454E4149 > Allocated locked data 0x0x7f8d46d0d1c0 > Unlocking key 534543524554532F5349442F4B454E4149 > release lock order 1 for /var/lib/samba/private/secrets.tdb > lock order: 1: 2: 3: > smbldap_search_ext: base => [cn=CASALOGIC.LAN,cn=kerberos,dc=casalogic,dc=lan], filter => [objectclass=krbrealmcontainer], scope => [0] > smbldap_open: already connected to the LDAP server > Attribute [krbDefaultEncSaltTypes] not found. > pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan > pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-CASALOGIC-LAN.socket has a valid init > smbldap_search_ext: base => [dc=casalogic,dc=lan], filter => [(&(objectClass=ipaNTUserAttrs)(uid=th))], scope => [2] > smbldap_open: already connected to the LDAP server > init_sam_from_ldap: Entry found for user: th > pdb_set_username: setting username th, was > element 11 -> now SET > pdb_set_domain: setting domain casalogic.lan, was > element 13 -> now DEFAULT > pdb_set_nt_username: setting nt username th, was > element 14 -> now SET > pdb_set_user_sid_from_string: setting user sid S-1-5-21-3663793457-3789003531-2001508300-2004 > pdb_set_user_sid: setting user sid S-1-5-21-3663793457-3789003531-2001508300-2004 > element 17 -> now SET > Segmentation fault > [root at kenai ~]# > > > > > > Can you send me a full backtrace of the core or the whole core file with > > the version of the samba.common package? > > > > I have captured a coredump with abrt. > Should I just send it directly to you? (20Mb uncompressed). yes, please do. bye, Sumit > > -- > 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 From natxo.asenjo at gmail.com Thu Nov 5 09:05:19 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Nov 2015 10:05:19 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work In-Reply-To: References: Message-ID: On Thu, Nov 5, 2015 at 10:03 AM, Natxo Asenjo wrote: > hi, > > since yesterday I have a strange situation in one of our joined hosts. > > i can login using a kerberos ticket, but not using name/password. > > In /var/log/secure I see this: > > sshd[29607]: pam_sss(sshd:auth): received for user username: 4 (System > error) > sorry, sent too early. how can I troubleshoot this issue? -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Nov 5 09:06:28 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Nov 2015 10:06:28 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work In-Reply-To: References: Message-ID: hi, this is in a centos host running 6.7, by the way. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Nov 5 09:14:55 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 5 Nov 2015 10:14:55 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work In-Reply-To: References: Message-ID: <20151105091455.GI3586@p.redhat.com> On Thu, Nov 05, 2015 at 10:05:19AM +0100, Natxo Asenjo wrote: > On Thu, Nov 5, 2015 at 10:03 AM, Natxo Asenjo > wrote: > > > hi, > > > > since yesterday I have a strange situation in one of our joined hosts. > > > > i can login using a kerberos ticket, but not using name/password. > > > > In /var/log/secure I see this: > > > > sshd[29607]: pam_sss(sshd:auth): received for user username: 4 (System > > error) > > > > sorry, sent too early. > > how can I troubleshoot this issue? You should check the SSSD debug logs, see https://fedorahosted.org/sssd/wiki/Troubleshooting for details about how to enable debug logging and where to find the logs. My guess is that SSSD has issues reaching a server so the domain log and the krb5_child log would be the files I'd check first. If the logs don't help you feel free to send them directly to me, if possible with debug level 10. HTH bye, Sumit > > -- > -- > Groeten, > natxo > -- > 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 From prashant at apigee.com Thu Nov 5 09:35:32 2015 From: prashant at apigee.com (Prashant Bapat) Date: Thu, 5 Nov 2015 15:05:32 +0530 Subject: [Freeipa-users] Upgrade from 4.1.4 In-Reply-To: References: <20151104091541.GF12746@mail.corp.redhat.com> <5639CE4E.9070302@redhat.com> <5639D099.5020104@redhat.com> <563A0C83.3040402@redhat.com> Message-ID: Please ignore my mails about tomcat/pki. An update fixed the issue. On 5 November 2015 at 12:58, Prashant Bapat wrote: > Looks like there are issues with dogtag and tomcat8. > http://pki.fedoraproject.org/wiki/Tomcat_8 > > On 5 November 2015 at 11:32, Prashant Bapat wrote: > >> New issue with upgrade. >> >> I setup a test IPA server. Its on AWS EC2 instance in a VPC. Fedora 21. >> freeipa 4.1.4. >> >> Upgraded OS from F21 --> F22 --> F23. All OK. >> >> Once in F23 *ipactl start* command tells me an upgrade is needed. >> >> Ran* ipa-server-upgrade* command. This command seems to do everything >> but somehow fails during upgrading the PKI (Tomcat). Now the tomcat service >> wont start. Other components are upgraded to 4.2.2 but Tomcat is down. >> >> Attached is the *ipaupgrade.log* and *catalina.2015-11-05.log*. >> >> Any help appreciated. >> >> Thanks. >> --Prashant >> >> On 5 November 2015 at 06:31, Prashant Bapat wrote: >> >>> Great idea! Is that possible ? Any documentation on how to do this would >>> be very helpful. >>> >>> Thanks. >>> >>> On 4 November 2015 at 19:17, Rob Crittenden wrote: >>> >>>> Martin Kosek wrote: >>>> > On 11/04/2015 10:27 AM, Prashant Bapat wrote: >>>> >> Ack. But in a live replicated setup wont upgrading from F21->F22 and >>>> >> F22->F23 take a long time. I mean couple of hours ? >>>> > >>>> > It will take some outage time, yes. But if you have appropriate >>>> number of >>>> > replicas and are upgrading one by one, you should be fine - the >>>> clients should >>>> > fail over to other replicas. >>>> > >>>> >> Are there any other ways to do this. Perhaps do a fresh install of >>>> F23 and >>>> >> then restore data from FreeIPA 4.1.4 (F21) ? >>>> > >>>> > FreeIPA upgrade also updates the data themselves. Restoring old data >>>> and >>>> > configuration files on fresh F23 using full backup + running the >>>> upgrade may >>>> > work, but there may be also a lot of hurdles. It is not really a >>>> tested approach. >>>> >>>> Or he could one by one install a new F23 system and configure it as a >>>> new master to replace one of the old ones until they are all running >>>> F23. >>>> >>>> I'm pretty sure backup/restore only works within the same version. >>>> >>>> rob >>>> >>>> > >>>> >> >>>> >> On 4 November 2015 at 14:52, Martin Kosek wrote: >>>> >> >>>> >>> On 11/04/2015 10:15 AM, Lukas Slebodnik wrote: >>>> >>>> On (04/11/15 14:37), Prashant Bapat wrote: >>>> >>>>> Hi All, >>>> >>>>> >>>> >>>>> We rolled out freeipa in our setup somewhere in beginning of >>>> 2015. Since >>>> >>>>> then there have been couple of new releases. Latest being 4.2.3. >>>> >>>>> >>>> >>>>> The FreeIPA servers are installed on Fedora 21 hosts and at this >>>> point >>>> >>>>> there is no direct way of upgrading to 4.2.3 unless we also >>>> upgrade the >>>> >>> OS. >>>> >>>>> The COPR repos do not support Fedora 21. >>>> >>>>> >>>> >>>> Fedora 23 was released yesterday. >>>> >>>> It means then Fedora 21 will be out of support in a month. >>>> >>>> I would definitelly recomment to upgrade it to newer Fedora. >>>> >>> >>>> >>> +1. I did the same actually for FreeIPA demo which was also running >>>> on F21 >>>> >>> before: >>>> >>> http://www.freeipa.org/page/Demo >>>> >>> I had to do it in two steps: F21->F22, F22->F23. >>>> >>> >>>> >>> If you make sure that F22->F23 upgrade updates to >>>> freeipa-4.2.3-1.fc23 or >>>> >>> later >>>> >>> (https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e), >>>> it >>>> >>> should >>>> >>> work just fine. >>>> >>> >>>> >>>> If you do not want t upgrade so often you might use FreeIPA >>>> >>>> on CentOS 7 >>>> >>>> >>>> >>>> LS >>>> >>>> >>>> >>> >>>> >>> >>>> >> >>>> > >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Nov 5 09:43:59 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Nov 2015 10:43:59 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work In-Reply-To: References: <20151105091455.GI3586@p.redhat.com> Message-ID: hi, Fixed, /tmp had the wrong permissions, was not owned by root:root. Thanks for the debugging tips! -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Thu Nov 5 10:50:45 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Thu, 5 Nov 2015 11:50:45 +0100 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: <563865D3.5030305@redhat.com> References: <563793D9.8050508@redhat.com> <563865D3.5030305@redhat.com> Message-ID: Hi, I waited a couple of days and when "dnf list freeipa-server --releasever=23" said 4.2.3 I hit the upgrade. Unfortunately I noticed to late that I received 4.2.2 during "dnf system-upgrade". Any ideas how to get it going again? Or is it easier to start from scratch if I only have ~ 10 IPA clients? -- john 2015-11-03 8:44 GMT+01:00 Martin Kosek : > On 11/02/2015 05:48 PM, Martin Kosek wrote: > > Hello everyone, > > > > Fedora 23 with the new and shiny FreeIPA 4.2 will be out tomorrow. The > release > > adds a lot of new exiting functionality and we are eager to hear your > thoughts > > on the release [1]. > > > > Unfortunately, the FreeIPA upgrade on Fedora 23 is broken at the moment > and > > fails on updating the LDAP schema. The problem is tracked in Red Hat > Bugzilla > > [2]. The problem is fixed in upstream project, the development team is > now > > working on releasing FreeIPA upstream release 4.2.3 ASAP and also > publishing it > > as a 0-day update for Fedora 23. This situation should be resolved within > > couple days, when the released build hits the official Fedora repos and > mirrors. > > > > Until the fixed FreeIPA version is released and in the Fedora repos, > please > > wait with updating your existing FreeIPA installation. > > > > We will keep you posted. We are very sorry for the inconvenience. > > > > [1] http://www.freeipa.org/page/Releases/4.2.0 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1274905 > > > > The respective F23 updates are now heading to testing repo: > > FreeIPA: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e > pki-core: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f12c332a2f > > Martin > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Nov 5 11:26:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Nov 2015 13:26:42 +0200 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: References: <563793D9.8050508@redhat.com> <563865D3.5030305@redhat.com> Message-ID: <20151105112642.GN8374@redhat.com> On Thu, 05 Nov 2015, John Obaterspok wrote: >Hi, > >I waited a couple of days and when "dnf list freeipa-server >--releasever=23" said 4.2.3 I hit the upgrade. Unfortunately I noticed to >late that I received 4.2.2 during "dnf system-upgrade". > >Any ideas how to get it going again? Or is it easier to start from scratch >if I only have ~ 10 IPA clients? Did you already upgrade to 4.2.3? Make sure you have pki-core-10.2.6-12.fc23 and freeipa 4.2.3-1.fc23, run ipa-server-upgrade. It should be able to recover. -- / Alexander Bokovoy From prashant at apigee.com Thu Nov 5 11:39:26 2015 From: prashant at apigee.com (Prashant Bapat) Date: Thu, 5 Nov 2015 17:09:26 +0530 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: References: <563793D9.8050508@redhat.com> <563865D3.5030305@redhat.com> Message-ID: I just upgraded a test env from 4.1.4 (F21) to 4.2.3 (F23) without issues. I had to run a dnf upgrade freeipa-server AFTER upgrading to F23 and then run ipa-server-upgrade. On 5 November 2015 at 16:20, John Obaterspok wrote: > Hi, > > I waited a couple of days and when "dnf list freeipa-server > --releasever=23" said 4.2.3 I hit the upgrade. Unfortunately I noticed to > late that I received 4.2.2 during "dnf system-upgrade". > > Any ideas how to get it going again? Or is it easier to start from scratch > if I only have ~ 10 IPA clients? > > -- john > > > 2015-11-03 8:44 GMT+01:00 Martin Kosek : > >> On 11/02/2015 05:48 PM, Martin Kosek wrote: >> > Hello everyone, >> > >> > Fedora 23 with the new and shiny FreeIPA 4.2 will be out tomorrow. The >> release >> > adds a lot of new exiting functionality and we are eager to hear your >> thoughts >> > on the release [1]. >> > >> > Unfortunately, the FreeIPA upgrade on Fedora 23 is broken at the moment >> and >> > fails on updating the LDAP schema. The problem is tracked in Red Hat >> Bugzilla >> > [2]. The problem is fixed in upstream project, the development team is >> now >> > working on releasing FreeIPA upstream release 4.2.3 ASAP and also >> publishing it >> > as a 0-day update for Fedora 23. This situation should be resolved >> within >> > couple days, when the released build hits the official Fedora repos and >> mirrors. >> > >> > Until the fixed FreeIPA version is released and in the Fedora repos, >> please >> > wait with updating your existing FreeIPA installation. >> > >> > We will keep you posted. We are very sorry for the inconvenience. >> > >> > [1] http://www.freeipa.org/page/Releases/4.2.0 >> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1274905 >> > >> >> The respective F23 updates are now heading to testing repo: >> >> FreeIPA: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4d94884a7e >> pki-core >> : >> https://bodhi.fedoraproject.org/updates/FEDORA-2015-f12c332a2f >> >> Martin >> >> -- >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Nov 5 09:30:10 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Nov 2015 10:30:10 +0100 Subject: [Freeipa-users] gssapi ssh works, pam user/password does not work In-Reply-To: <20151105091455.GI3586@p.redhat.com> References: <20151105091455.GI3586@p.redhat.com> Message-ID: hi Sumit, On Thu, Nov 5, 2015 at 10:14 AM, Sumit Bose wrote: > > how can I troubleshoot this issue? > > You should check the SSSD debug logs, see > https://fedorahosted.org/sssd/wiki/Troubleshooting for details about how > to enable debug logging and where to find the logs. > > My guess is that SSSD has issues reaching a server so the domain log and > the krb5_child log would be the files I'd check first. > > If the logs don't help you feel free to send them directly to me, if > possible with debug level 10. > > HTH > > bye, > Sumit > I see this in krb5_child.log: Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [main] (0x0400): krb5_child started. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [unpack_buffer] (0x1000): total buffer size: [175] (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [unpack_buffer] (0x0100): cmd [241] uid [1063000036] gid [1063000036] validate [true] enterprise principal [false] offline [false] UPN [ capitar.admin at UNIX.IRISZORG.NL] (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1063000036_XXXXXX] old_ccname: [FILE:/tmp/krb5cc_1063000036_DKHexY] keytab: [/etc/krb5.keytab] (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [old_ccache_valid] (0x0400): Saved ccache FILE:/tmp/krb5cc_1063000036_DKHexY doesn't exist, ignoring (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [FILE:/tmp/krb5cc_1063000036_DKHexY] and is not active and TGT is not valid. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [check_parent_stat] (0x0020): Private directory can only be created below a directory belonging to root or to [1063000036]. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [create_ccache_dir] (0x0010): Check the ownership and permissions of krb5_ccachedir: [/tmp]. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [k5c_precreate_ccache] (0x0040): ccache creation failed. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [k5c_ccache_setup] (0x0040): Cannot precreate ccache (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [privileged_krb5_setup] (0x0020): k5c_ccache_setup failed. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [main] (0x0020): privileged_krb5_setup failed. (Thu Nov 5 10:23:50 2015) [[sssd[krb5_child[13083]]]] [main] (0x0020): krb5_child failed! -- Groeten, na -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Thu Nov 5 14:47:07 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 15:47:07 +0100 Subject: [Freeipa-users] Client enrolment user Message-ID: Some time ago I saw an article on how to set up a user that can only enrol clients into freeipa. Does anyone have information on how to do this because we're currently using the admin user and this is a bit scary. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 5 14:51:37 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 09:51:37 -0500 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> Message-ID: <563B6CF9.4020501@redhat.com> Prasun Gera wrote: > Yes, that's what I was planning to do. i.e. Convert cipher names from > SSL to NSS. I wasn't sure about the other settings though. Is there an > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there > equivalent configs for HSTS on the mozilla page? Does NSS allow using > generated DH parameters instead of standard ones ? For SSL, the > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters > "{path to dhparams.pem}"' after generating the params. NSS does not let the user specify cipher order. It uses its own internal sorting from strongest to weakest. HSTS is a header and not dependent upon SSL provider. mod_nss doesn't support DH ciphers. rob > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale > wrote: > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > Thanks for the ticket information. I would still be interested in > > configuring mod_nss properly (irrespective of whether the certs are ipa > > generated or 3rd party). These are the worrying notes from ssllabs test: > > > > The server supports only older protocols, but not the current best TLS 1.2. > > Grade capped to C. > > This server accepts the RC4 cipher, which is weak. Grade capped to B. > > The server does not support Forward Secrecy with the reference browsers. > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > starting point. See also the "Cipher names correspondence table" on > the same page for translating it to cipher names understood by NSS > to construct a valid setting for the `NSSCipherSuite' directive. > > [1] > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > Cheers, > Fraser > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > wrote: > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible > publicly. > > > I'm > > > > using a stock configuration which uses the certs signed by > ipa's CA for > > > the > > > > webui. This is mostly for convenience since it manages renewals > > > seamlessly. > > > > This, however, requires users to add the CA as trusted to their > > > browsers. A > > > > promising alternative to this is https://letsencrypt.org/, > which issues > > > > browser trusted certs, and will manage auto renewals too (in > the future). > > > > As a feature request, it would be nice to have closer > integration between > > > > ipa and the letsencrypt client which would make managing certs > simple. > > > I'm > > > > about to set this up manually right now using the external ssl > certs > > > guide. > > > > > > > Let's Encrypt is on our radar. I like the idea of being able to > > > install FreeIPA with publicly-trusted certs for HTTP and LDAP from > > > the beginning. This would require some work in ipa-server-install > > > in addition to certmonger support and a good, stable Let's Encrypt / > > > ACME client implementation for Apache on Fedora. > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common activity > > > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431 > > > > > > Cheers, > > > Fraser > > > > > > > Secondly, since the webui uses mod_nss, how would one set it > up to prefer > > > > security over compatibility with older clients ? The vast > majority of > > > > documentation online (for eg. > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > > about > > > > mod_ssl and I think the configuration doesn't transfer directly to > > > mod_nss. > > > > Since this is the only web facing component, I would like to > set it up to > > > > use stringent requirements. Right now, a test on > > > > https://www.ssllabs.com/ssltest/ and > https://weakdh.org/sysadmin.html > > > > identifies > > > > several issues. Since these things are not really my area of > expertise, I > > > > would like some documentation regarding this. Also, would manually > > > > modifying any of the config files be overwritten by a yum update ? > > > > > > > -- > > > > 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 > > > > > > > > > > From rcritten at redhat.com Thu Nov 5 15:18:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 10:18:42 -0500 Subject: [Freeipa-users] Client enrolment user In-Reply-To: References: Message-ID: <563B7352.8090901@redhat.com> Andrew Holway wrote: > Some time ago I saw an article on how to set up a user that can only > enrol clients into freeipa. > > Does anyone have information on how to do this because we're currently > using the admin user and this is a bit scary. Create a role for enrolling hosts and add the privilege 'Host Enrollment' to it. Note that 'Host Enrollment' is VERY specific. It only enrolls host. It will not create host entries. If you want to be able to do that as well then you'll need the 'Add Hosts' permission. I guess I'd create a new privilege and add that permission, then add that privilege to the role you create. Some folks add the existing 'Host Administrators' privilege instead but IMHO that is a bit broad. rob From andrew.holway at gmail.com Thu Nov 5 15:58:02 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 16:58:02 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica Message-ID: One of our FreeIPA replicas had its filesystem hosed so we want to remove it. Can someone show me the sequence of commands to remove a down replica? Thanks, Andrew [root at freeipa-prod-a-033 centos]# ipa-replica-manage list p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute freeipa-prod-a-031.cloud.foo.com: master freeipa-prod-a-033.cloud.foo.com: master freeipa-prod-b-032.cloud.foo.com: master [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force freeipa-prod-a-031.foo.dcmn.com p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for ' freeipa-prod-a-031.cloud.dcmn.com' -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Thu Nov 5 16:32:45 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 17:32:45 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: References: Message-ID: Actually I'm starting to feel like this is a bug. Managed to get the old IPA server back up and ran . "ipa-server-install --uninstall" Which completed successfully and gave the advice: Replication agreements with the following IPA masters found: freeipa- prod-b-032.cloud.foo.com. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com Running this command on the other IPA servers gives the following: [root at freeipa-prod-a-033 centos]# ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for ' freeipa-prod-a-031.cloud.foo.com' I dont see anything in the logs. Thanks, Andrew On 5 November 2015 at 16:58, Andrew Holway wrote: > One of our FreeIPA replicas had its filesystem hosed so we want to remove > it. Can someone show me the sequence of commands to remove a down replica? > > Thanks, > > Andrew > > > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage list > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > freeipa-prod-a-031.cloud.foo.com: master > > freeipa-prod-a-033.cloud.foo.com: master > > freeipa-prod-b-032.cloud.foo.com: master > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force > freeipa-prod-a-031.foo.dcmn.com > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for ' > freeipa-prod-a-031.cloud.dcmn.com' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marat.vyshegorodtsev at gmail.com Thu Nov 5 13:39:48 2015 From: marat.vyshegorodtsev at gmail.com (Marat Vyshegorodtsev) Date: Thu, 5 Nov 2015 22:39:48 +0900 Subject: [Freeipa-users] FreeIPA Server with ECC certificate in LDAPS (389DS) Message-ID: Hi! I've been fighting for the past week with FreeIPA and trying to make it work with my own CA certificate that is ECDSA_SHA256. Even though I somehow fixed /etc/httpd/conf.d/nss.conf to make it work (basically added correct NSSCipherSuite), LDAP (389DS) is a tough nut. The command I used is: ipa-server-install --mkhomedir --hostname 'ipa.mydomain.com' --realm MYDOMAIN.COM --domain mydomain.com --ds-password 'DS_PASSWORD_HERE' --admin-password 'ADMIN_PASSWORD_HERE' --no-ntp --unattended --no-host-dns --dirsrv-cert-file /etc/ipa/ipa.p12 --http-cert-file /etc/ipa/ipa.p12 --dirsrv-pin 'PIN_FOR_CERT' --http-pin 'PIN_FOR_CERT' --ca-cert-file /etc/ipa/myownca.pem In this case, installation fails at the following step: Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' 'ipa.rpay.us' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' '/var/lib/ipa/tmp5KkCae' '-T' '/var/lib/ipa/tmpTC27Ap' 'uid=admin,cn=users,cn=accounts,dc=rpay,dc=us'' returned non-zero exit status 1 In /var/log/ipaserver-install.log I see a message: DEBUG stderr=ldap_start_tls: Protocol error (2) additional info: SSL not supported by this server. Basically, LDAP is broken now (it doesn't allow connecting without -ZZ flag, and fails with it, since TLS is misconfigured at this point). What actually happens, LDAP gets configured to use RSA as a key exchange algorithm, and fails, since the cert is an ECC cert. In /var/log/dirsrv/slapd-MYDOMAIN-COM/errors you can see: [05/Nov/2015:12:22:36 +0000] - SSL alert: ConfigSecureServer: Server key/certificate is bad for cert FreeIPA of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -12200 - The certificate provided cannot be used with the selected key exchange algorithm.) This is configured by ipaserver/install/dsinstance.py under def __enable_ssl: entry = conn.make_entry( DN(('cn', 'RSA'), ('cn', 'encryption'), ('cn', 'config')), objectclass=["top", "nsEncryptionModule"], cn=["RSA"], nsSSLPersonalitySSL=[self.nickname], nsSSLToken=["internal (software)"], nsSSLActivation=["on"], ) conn.add_entry(entry) My question is, is it possible to replace RSA with ECDSA here? If so, what parameters should I pass to LDAP? If this is fixable, can someone add autodetect of the type of the certificate and enable appropriate algorithms in LDAP and Apache? Best regards, Marat Vyshegorodtsev From cal-s at blue-bolt.com Thu Nov 5 16:36:51 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Thu, 5 Nov 2015 16:36:51 +0000 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563A262A.3050207@redhat.com> References: <563A0D3E.4020009@blue-bolt.com> <563A0E88.90705@redhat.com> <563A203C.8030601@blue-bolt.com> <563A262A.3050207@redhat.com> Message-ID: <563B85A3.9080108@blue-bolt.com> Done and done, although imported users' membership in their OpenLDAP primary group wasn't preserved because a al catch22, that group could be made default until it was imported, but was easily rectified via the UI I can almost live with these gigantic UIDs set for new users but the default GID, in spite of having set the default group (which is respected, but i would have expected the default GID to follow?) gets set to some unique and amusingly massive value. i've trawled a few old list posts but as with any project that spans years, you never know if you're reading something that became definitive or not, so i ask again: Is it possible to pin new users' GID to my POSIX legacy "all-users" GID? And is it possible to elect a starting UID? Doesn't (although i'd prefer it) have to be a continuation of the POSIX range (1100+) i imported but something more humanly parseable would be better. In spite of an early post i came across which says "consider that future merger", it ain;'t going to happen on a F500 scale for us Now for something completely different(ish): why was 4.x never build as EL6 RPMs? I am "mildly" resenting having to set up EL7, with all of it's uncharming peculiarities, in order to get relatively recent IPA 4.1 thus preserving future upgradability. Thanks very much, Rob and Martin, for your quick and helpful replies cheers Cal Sawyer | Systems Engineer | BlueBolt Ltd On 04/11/15 15:37, Rob Crittenden wrote: > Cal Sawyer wrote: >> That's terrific, Rob - thanks very much. Users and Groups import >> smoothly with a little additional tweaking >> >> ipa -v migrate-ds --with-compat >> --bind-dn="cn=Manager,dc=ldapdomain,dc=local" >> --user-container="ou=People,dc=blue-bolt,dc=local" >> --group-container="ou=Group,dc=ldapdomain,dc=local" >> --group-objectclass="posixGroup" ldap://1.2.3.4:389 >> >> boom, all users and groups imported ... but without group membership. > This is the RFC2307 schema. I think to fix you'd have to delete all IPA > users and groups and re-migrate. > >> The structure of Group in OpenLDAP is: >> >> # power, Group, ldapdomain.local >> dn: cn=systems,ou=Group,dc=ldapdomain,dc=local >> cn: systems >> gidNumber: 1112 >> objectClass: posixGroup >> memberUid: usera >> memberUid: userb >> >> >> and IPA's schema appears, with one exception (objectClass: top), to match: >> >> # admins, groups, compat, ipadomain.local >> dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local >> objectClass: posixGroup >> objectClass: top >> gidNumber: 1944000000 >> memberUid: admin >> cn: admins > That's the rfc 2307 compatibility view. If you look in > cn=admins,cn=groups,cn=accounts,dc=ipadomain,dc=local you'll see how it > is actually stored. > >> A side question: can i use migrate-ds to bring in automount and sudoer >> maps from OpenLDAP? > It's only users and groups right now. > > You might have some luck with automount importing via LDIF but at least > the DN structure will need to be modified. You'd need to be pretty > careful that the IPA schema matches your current schema. > > I think with sudo you'd be out of luck as IPA uses its own schema for > storing the sudo components and rules. > > rob >> thanks again >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> 15-16 Margaret Street | London W1W 8RW >> +44 (0)20 7637 5575 | www.blue-bolt.com >> >> On 04/11/15 13:56, Rob Crittenden wrote: >>> Cal Sawyer wrote: >>>> Hi >>>> >>>> Very new to IPA and setting up a proof of concept system that i hope >>>> will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to >>>> import People, Group ou's into IPA using "ipa migrate-ds". The IPA and >>>> existing LDAP directories have different BaseDNs (eg ipadomain.local on >>>> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a >>>> completely new directory that we will then switch our clients over to. >>>> >>>> ipa migrate-ds --schema=RFC2307 >>>> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 >>>> >>>> whatever i try (w or w/o --schema=RFC2307) , the response is the same: >>>> >>>> ipa: ERROR: Insufficient access: Invalid credentials >>>> >>>> or with a verbose flag: >>>> >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> u'https://ipa.ipadomain.local/ipa/session/xml' >>>> ipa: ERROR: Insufficient access: Invalid credentials >>>> >>>> manager naturally exists in ldapdomain.local and i've definitely >>>> supplied the correct password (we use the same creds to manage LDAP >>>> using phpldapadmin) >>>> >>>> Hoping that someone has some experience with this and can point me in >>>> the right direction? >>> It is binding to openldap using cn=Directory Manager. If your admin user >>> that can read userPassword is named something different then pass it in >>> using the --binddn option. >>> >>> rob >>> From andrew.holway at gmail.com Thu Nov 5 16:37:31 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 17:37:31 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: References: Message-ID: The now dead IPA server is still seen as authoritative for the domain. [root at freeipa-prod-a-033 centos]# dig NS cloud.foo.com +short freeipa-prod-b-032.cloud.foo.com. freeipa-prod-a-033.cloud.foo.com. freeipa-prod-a-031.cloud.foo.com. On 5 November 2015 at 17:32, Andrew Holway wrote: > Actually I'm starting to feel like this is a bug. Managed to get the old > IPA server back up and ran . > > "ipa-server-install --uninstall" > > Which completed successfully and gave the advice: > > Replication agreements with the following IPA masters found: freeipa- > > prod-b-032.cloud.foo.com. Removing any replication agreements before > > uninstalling the server is strongly recommended. You can remove replication > > agreements by running the following command on any other IPA master: > > $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com > > > Running this command on the other IPA servers gives the following: > > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage del > freeipa-prod-a-031.cloud.foo.com > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for ' > freeipa-prod-a-031.cloud.foo.com' > > > I dont see anything in the logs. > > > Thanks, > > > Andrew > > On 5 November 2015 at 16:58, Andrew Holway > wrote: > >> One of our FreeIPA replicas had its filesystem hosed so we want to remove >> it. Can someone show me the sequence of commands to remove a down replica? >> >> Thanks, >> >> Andrew >> >> >> >> [root at freeipa-prod-a-033 centos]# ipa-replica-manage list >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> freeipa-prod-a-031.cloud.foo.com: master >> >> freeipa-prod-a-033.cloud.foo.com: master >> >> freeipa-prod-b-032.cloud.foo.com: master >> >> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force >> freeipa-prod-a-031.foo.dcmn.com >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for ' >> freeipa-prod-a-031.cloud.dcmn.com' >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcnt at use.startmail.com Thu Nov 5 16:44:02 2015 From: jcnt at use.startmail.com (jcnt at use.startmail.com) Date: Thu, 5 Nov 2015 11:44:02 -0500 Subject: [Freeipa-users] problems with NFS service principal Message-ID: Hello everyone, I initially followed freeipa NFS documentation for setting up external stand alone NFS server ipa host-add mickey.corp.example.org ipa service-add nfs/mickey.corp.example.org ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org -k /tmp/nfs.keytab uploaded keytab to NFS server and all appeared to work just fine: mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf mickey> kinit admin Password for admin at CORP.EXAMPLE.ORG: XXXXXXX mickey> klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at CORP.EXAMPLE.ORG Valid starting Expires Service principal 05/16/2015 18:17:00 05/17/2015 18:16:50 krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG mickey> kinit -k -t /etc/nfs/krb5.keytab nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG mickey> klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG Valid starting Expires Service principal 05/16/2015 23:48:14 05/17/2015 23:48:13 krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG mickey> However, I learned hard way (NFS stopped working) that ipa-getkeytab issues ticket with a default timeout of 3 months. I repeated ipa-getkeytab and got: mickey> kinit -k -t /etc/nfs/krb5.keytab kinit: Keytab contains no suitable keys for host/mickey.corp.example.org at CORP.EXAMPLE.ORG while getting initial credentials mickey> klist -k -t /etc/nfs/krb5.keytab Keytab name: FILE:/etc/nfs/krb5.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG When client tries to mount: # mount -vvv -o sec=krb5 mickey:/volume1/homes /mnt mount.nfs: timeout set for Thu Nov 5 11:41:39 2015 mount.nfs: trying text-based options 'sec=krb5,vers=4,addr=192.168.26.2,clientaddr=192.168.26.31' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified Not much information available... Any NFS experts out here? Thanks, Josh. From coy.hile at coyhile.com Thu Nov 5 16:41:20 2015 From: coy.hile at coyhile.com (Coy Hile) Date: Thu, 05 Nov 2015 16:41:20 +0000 Subject: [Freeipa-users] Client enrolment user Message-ID: <20151105164120.Horde.5mpschIyKed59TQqmHBYOw1@webmail01.coyhile.com> Is there documentation thst states explicitly which permissions are granted to the Various built in roles? Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone -------- Original message -------- From: Rob Crittenden Date: 11/05/2015 10:18 (GMT-05:00) To: Freeipa-users at redhat.com, andrew.holway at gmail.com Subject: Re: [Freeipa-users] Client enrolment user > Andrew Holway wrote: >> Some time ago I saw an article on how to set up a user that can only >> enrol clients into freeipa. >> >> Does anyone have information on how to do this because we're currently >> using the admin user and this is a bit scary. > > Create a role for enrolling hosts and add the privilege 'Host > Enrollment' to it. > > Note that 'Host Enrollment' is VERY specific. It only enrolls host. It > will not create host entries. If you want to be able to do that as well > then you'll need the 'Add Hosts' permission. I guess I'd create a new > privilege and add that permission, then add that privilege to the role > you create. > > Some folks add the existing 'Host Administrators' privilege instead but > IMHO that is a bit broad. > > 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 > From rcritten at redhat.com Thu Nov 5 17:04:23 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 12:04:23 -0500 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: References: Message-ID: <563B8C17.8030908@redhat.com> Andrew Holway wrote: > Actually I'm starting to feel like this is a bug. Managed to get the old > IPA server back up and ran . > > "ipa-server-install --uninstall" > > Which completed successfully and gave the advice: > > Replication agreements with the following IPA masters found: freeipa- > > prod-b-032.cloud.foo.com . Removing any > replication agreements before > > uninstalling the server is strongly recommended. You can remove replication > > agreements by running the following command on any other IPA master: > > $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com > > > > Running this command on the other IPA servers gives the following: > > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage del > freeipa-prod-a-031.cloud.foo.com > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > 'freeipa-prod-a-033.cloud.dcmn.com > ' has no replication agreement > for 'freeipa-prod-a-031.cloud.foo.com > ' > > > I dont see anything in the logs. Perhaps you had already force deleted the agreement on freeipa-prod-a-033.cloud.dcmn.com after freeipa-prod-a-031.cloud.foo.com went down. rob > > > Thanks, > > > Andrew > > > On 5 November 2015 at 16:58, Andrew Holway > wrote: > > One of our FreeIPA replicas had its filesystem hosed so we want to > remove it. Can someone show me the sequence of commands to remove a > down replica? > > Thanks, > > Andrew > > > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage list > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported > attribute > > freeipa-prod-a-031.cloud.foo.com > : master > > freeipa-prod-a-033.cloud.foo.com > : master > > freeipa-prod-b-032.cloud.foo.com > : master > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force > freeipa-prod-a-031.foo.dcmn.com > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported > attribute > > 'freeipa-prod-a-033.cloud.foo.com > ' has no replication > agreement for 'freeipa-prod-a-031.cloud.dcmn.com > ' > > > > From rcritten at redhat.com Thu Nov 5 17:13:11 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 12:13:11 -0500 Subject: [Freeipa-users] Unable to import OpenLDAP users/groups with migrate-ds In-Reply-To: <563B85A3.9080108@blue-bolt.com> References: <563A0D3E.4020009@blue-bolt.com> <563A0E88.90705@redhat.com> <563A203C.8030601@blue-bolt.com> <563A262A.3050207@redhat.com> <563B85A3.9080108@blue-bolt.com> Message-ID: <563B8E27.3020504@redhat.com> Cal Sawyer wrote: > Done and done, although imported users' membership in their OpenLDAP > primary group wasn't preserved because a al catch22, that group could be > made default until it was imported, but was easily rectified via the UI > > I can almost live with these gigantic UIDs set for new users but the > default GID, in spite of having set the default group (which is > respected, but i would have expected the default GID to follow?) gets > set to some unique and amusingly massive value. i've trawled a few old > list posts but as with any project that spans years, you never know if > you're reading something that became definitive or not, so i ask again: I'd have expected the GID to remain. It should try to keep the existing GID as long as there is a group on the remote LDAP server has a group with the posixgroup objectclass and the matching gidnumber. I don't believe the default users group has any effect here. /var/log/httpd/error_log should contain a bunch of info on the migrated users. > Is it possible to pin new users' GID to my POSIX legacy "all-users" > GID? And is it possible to elect a starting UID? Doesn't (although i'd > prefer it) have to be a continuation of the POSIX range (1100+) i > imported but something more humanly parseable would be better. In spite > of an early post i came across which says "consider that future merger", > it ain;'t going to happen on a F500 scale for us You can specify the id ranges when running ipa-server-install. > > Now for something completely different(ish): why was 4.x never build as > EL6 RPMs? I am "mildly" resenting having to set up EL7, with all of > it's uncharming peculiarities, in order to get relatively recent IPA 4.1 > thus preserving future upgradability. Because the dependency chain was too great. RHEL is about stability and changing the KDC, LDAP server, CA, Samba and a slew of other things is just too much. rob > > Thanks very much, Rob and Martin, for your quick and helpful replies > > cheers > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > > On 04/11/15 15:37, Rob Crittenden wrote: >> Cal Sawyer wrote: >>> That's terrific, Rob - thanks very much. Users and Groups import >>> smoothly with a little additional tweaking >>> >>> ipa -v migrate-ds --with-compat >>> --bind-dn="cn=Manager,dc=ldapdomain,dc=local" >>> --user-container="ou=People,dc=blue-bolt,dc=local" >>> --group-container="ou=Group,dc=ldapdomain,dc=local" >>> --group-objectclass="posixGroup" ldap://1.2.3.4:389 >>> >>> boom, all users and groups imported ... but without group membership. >> This is the RFC2307 schema. I think to fix you'd have to delete all IPA >> users and groups and re-migrate. >> >>> The structure of Group in OpenLDAP is: >>> >>> # power, Group, ldapdomain.local >>> dn: cn=systems,ou=Group,dc=ldapdomain,dc=local >>> cn: systems >>> gidNumber: 1112 >>> objectClass: posixGroup >>> memberUid: usera >>> memberUid: userb >>> >>> >>> and IPA's schema appears, with one exception (objectClass: top), to >>> match: >>> >>> # admins, groups, compat, ipadomain.local >>> dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local >>> objectClass: posixGroup >>> objectClass: top >>> gidNumber: 1944000000 >>> memberUid: admin >>> cn: admins >> That's the rfc 2307 compatibility view. If you look in >> cn=admins,cn=groups,cn=accounts,dc=ipadomain,dc=local you'll see how it >> is actually stored. >> >>> A side question: can i use migrate-ds to bring in automount and sudoer >>> maps from OpenLDAP? >> It's only users and groups right now. >> >> You might have some luck with automount importing via LDIF but at least >> the DN structure will need to be modified. You'd need to be pretty >> careful that the IPA schema matches your current schema. >> >> I think with sudo you'd be out of luck as IPA uses its own schema for >> storing the sudo components and rules. >> >> rob >>> thanks again >>> >>> Cal Sawyer | Systems Engineer | BlueBolt Ltd >>> 15-16 Margaret Street | London W1W 8RW >>> +44 (0)20 7637 5575 | www.blue-bolt.com >>> >>> On 04/11/15 13:56, Rob Crittenden wrote: >>>> Cal Sawyer wrote: >>>>> Hi >>>>> >>>>> Very new to IPA and setting up a proof of concept system that i hope >>>>> will replace my existing OpenLDAP 2.3 (no SASL) setup. I'm trying to >>>>> import People, Group ou's into IPA using "ipa migrate-ds". The IPA >>>>> and >>>>> existing LDAP directories have different BaseDNs (eg >>>>> ipadomain.local on >>>>> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a >>>>> completely new directory that we will then switch our clients over to. >>>>> >>>>> ipa migrate-ds --schema=RFC2307 >>>>> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389 >>>>> >>>>> whatever i try (w or w/o --schema=RFC2307) , the response is the same: >>>>> >>>>> ipa: ERROR: Insufficient access: Invalid credentials >>>>> >>>>> or with a verbose flag: >>>>> >>>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>>> u'https://ipa.ipadomain.local/ipa/session/xml' >>>>> ipa: ERROR: Insufficient access: Invalid credentials >>>>> >>>>> manager naturally exists in ldapdomain.local and i've definitely >>>>> supplied the correct password (we use the same creds to manage LDAP >>>>> using phpldapadmin) >>>>> >>>>> Hoping that someone has some experience with this and can point me in >>>>> the right direction? >>>> It is binding to openldap using cn=Directory Manager. If your admin >>>> user >>>> that can read userPassword is named something different then pass it in >>>> using the --binddn option. >>>> >>>> rob >>>> > From andrew.holway at gmail.com Thu Nov 5 15:46:28 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 16:46:28 +0100 Subject: [Freeipa-users] Client enrolment user In-Reply-To: References: <563B7352.8090901@redhat.com> Message-ID: I'm finding that the new client to be installed is not accepting the password of my new host enrolment user. This password is working fine with kinit on other hosts and also working in the GUI. Any ideas what I am doing wrong here? On 5 November 2015 at 16:42, Andrew Holway wrote: > Thanks! > > On 5 November 2015 at 16:18, Rob Crittenden wrote: > >> Andrew Holway wrote: >> > Some time ago I saw an article on how to set up a user that can only >> > enrol clients into freeipa. >> > >> > Does anyone have information on how to do this because we're currently >> > using the admin user and this is a bit scary. >> >> Create a role for enrolling hosts and add the privilege 'Host >> Enrollment' to it. >> >> Note that 'Host Enrollment' is VERY specific. It only enrolls host. It >> will not create host entries. If you want to be able to do that as well >> then you'll need the 'Add Hosts' permission. I guess I'd create a new >> privilege and add that permission, then add that privilege to the role >> you create. >> >> Some folks add the existing 'Host Administrators' privilege instead but >> IMHO that is a bit broad. >> >> rob >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Thu Nov 5 15:42:17 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Nov 2015 16:42:17 +0100 Subject: [Freeipa-users] Client enrolment user In-Reply-To: <563B7352.8090901@redhat.com> References: <563B7352.8090901@redhat.com> Message-ID: Thanks! On 5 November 2015 at 16:18, Rob Crittenden wrote: > Andrew Holway wrote: > > Some time ago I saw an article on how to set up a user that can only > > enrol clients into freeipa. > > > > Does anyone have information on how to do this because we're currently > > using the admin user and this is a bit scary. > > Create a role for enrolling hosts and add the privilege 'Host > Enrollment' to it. > > Note that 'Host Enrollment' is VERY specific. It only enrolls host. It > will not create host entries. If you want to be able to do that as well > then you'll need the 'Add Hosts' permission. I guess I'd create a new > privilege and add that permission, then add that privilege to the role > you create. > > Some folks add the existing 'Host Administrators' privilege instead but > IMHO that is a bit broad. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 5 18:51:40 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 13:51:40 -0500 Subject: [Freeipa-users] Client enrolment user In-Reply-To: <20151105164120.Horde.5mpschIyKed59TQqmHBYOw1@webmail01.coyhile.com> References: <20151105164120.Horde.5mpschIyKed59TQqmHBYOw1@webmail01.coyhile.com> Message-ID: <563BA53C.309@redhat.com> Coy Hile wrote: > > > Is there documentation thst states explicitly which permissions are > granted to the Various built in roles? No but it is easy enough to determine using either the UI or cli. The provided roles are more of an example than anything. If there are specific role suggestions they would be seriously entertained. rob > > > Sent via the Samsung GALAXY S? 5, an AT&T 4G LTE smartphone > > -------- Original message -------- > From: Rob Crittenden > Date: 11/05/2015 10:18 (GMT-05:00) > To: Freeipa-users at redhat.com, andrew.holway at gmail.com > Subject: Re: [Freeipa-users] Client enrolment user > >> Andrew Holway wrote: >>> Some time ago I saw an article on how to set up a user that can only >>> enrol clients into freeipa. >>> >>> Does anyone have information on how to do this because we're currently >>> using the admin user and this is a bit scary. >> >> Create a role for enrolling hosts and add the privilege 'Host >> Enrollment' to it. >> >> Note that 'Host Enrollment' is VERY specific. It only enrolls host. It >> will not create host entries. If you want to be able to do that as well >> then you'll need the 'Add Hosts' permission. I guess I'd create a new >> privilege and add that permission, then add that privilege to the role >> you create. >> >> Some folks add the existing 'Host Administrators' privilege instead but >> IMHO that is a bit broad. >> >> 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 >> > From rcritten at redhat.com Thu Nov 5 18:54:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 13:54:10 -0500 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: References: Message-ID: <563BA5D2.5020904@redhat.com> jcnt at use.startmail.com wrote: > Hello everyone, > > I initially followed freeipa NFS documentation for setting up external stand alone NFS server > > ipa host-add mickey.corp.example.org > ipa service-add nfs/mickey.corp.example.org > ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org -k /tmp/nfs.keytab > > uploaded keytab to NFS server and all appeared to work just fine: > > mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf Why are you using a custom krb5.conf? > mickey> kinit admin > Password for admin at CORP.EXAMPLE.ORG: XXXXXXX > mickey> klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at CORP.EXAMPLE.ORG > > Valid starting Expires Service principal > 05/16/2015 18:17:00 05/17/2015 18:16:50 krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG > mickey> kinit -k -t /etc/nfs/krb5.keytab nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > mickey> klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > > Valid starting Expires Service principal > 05/16/2015 23:48:14 05/17/2015 23:48:13 krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG > mickey> > > However, I learned hard way (NFS stopped working) that ipa-getkeytab issues ticket with a default timeout of 3 months. keytabs don't time out. What made you think it has a 3-month validity period? > > I repeated ipa-getkeytab and got: > > mickey> kinit -k -t /etc/nfs/krb5.keytab > kinit: Keytab contains no suitable keys for host/mickey.corp.example.org at CORP.EXAMPLE.ORG while getting initial credentials > mickey> klist -k -t /etc/nfs/krb5.keytab > Keytab name: FILE:/etc/nfs/krb5.keytab > KVNO Timestamp Principal > ---- ------------------- ------------------------------------------------------ > 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG You used the right command earlier: # kinit -k -t /etc/nfs/krb5.keytab nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > When client tries to mount: > > # mount -vvv -o sec=krb5 mickey:/volume1/homes /mnt > mount.nfs: timeout set for Thu Nov 5 11:41:39 2015 > mount.nfs: trying text-based options 'sec=krb5,vers=4,addr=192.168.26.2,clientaddr=192.168.26.31' > mount.nfs: mount(2): Invalid argument > mount.nfs: an incorrect mount option was specified > > Not much information available... > > Any NFS experts out here? The NFS server may have more info. rob From brian at interlinx.bc.ca Thu Nov 5 21:14:10 2015 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 05 Nov 2015 16:14:10 -0500 Subject: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts In-Reply-To: <1446669474.22705.126.camel@interlinx.bc.ca> References: <1446669474.22705.126.camel@interlinx.bc.ca> Message-ID: <1446758050.22705.177.camel@interlinx.bc.ca> On Wed, 2015-11-04 at 15:37 -0500, Brian J. Murrell wrote: > I am trying to re-enroll clients after re-installing their O/S (EL6) > using: > > # ipa-client-install --force-join ... > > Per http://www.freeipa.org/page/V3/Forced_client_re-enrollment but I > am > finding that after doing that for a given host, trying to ssh to it > from another enrolled IPA client I am getting: > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle > attack)! > It is also possible that a host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 15:db:4d:e2:8b:c2:b8:3d:da:93:90:06:f2:f1:d6:21. > Please contact your system administrator. > Add correct host key in /dev/null to get rid of this message. > Offending DSA key in /var/lib/sss/pubconf/known_hosts:4 > Keyboard-interactive authentication is disabled to avoid man-in-the > -middle attacks. > Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). So the problem here was not really anything to do with the above but rather that ipa-client-install is flaky and can fail when running it a few seconds later it succeeds. Since I am provisioning multiple systems at a time in a script, it was not clearly obvious to me that it was failing. And so when ipa-client-install flakes out, of course what is left is the previous instance of the node in FreeIPA complete with the previous instance's SSH keys. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Nov 5 21:25:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 16:25:33 -0500 Subject: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts In-Reply-To: <1446758050.22705.177.camel@interlinx.bc.ca> References: <1446669474.22705.126.camel@interlinx.bc.ca> <1446758050.22705.177.camel@interlinx.bc.ca> Message-ID: <563BC94D.5020301@redhat.com> Brian J. Murrell wrote: > On Wed, 2015-11-04 at 15:37 -0500, Brian J. Murrell wrote: >> I am trying to re-enroll clients after re-installing their O/S (EL6) >> using: >> >> # ipa-client-install --force-join ... >> >> Per http://www.freeipa.org/page/V3/Forced_client_re-enrollment but I >> am >> finding that after doing that for a given host, trying to ssh to it >> from another enrolled IPA client I am getting: >> >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ >> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! >> Someone could be eavesdropping on you right now (man-in-the-middle >> attack)! >> It is also possible that a host key has just been changed. >> The fingerprint for the RSA key sent by the remote host is >> 15:db:4d:e2:8b:c2:b8:3d:da:93:90:06:f2:f1:d6:21. >> Please contact your system administrator. >> Add correct host key in /dev/null to get rid of this message. >> Offending DSA key in /var/lib/sss/pubconf/known_hosts:4 >> Keyboard-interactive authentication is disabled to avoid man-in-the >> -middle attacks. >> Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). > > So the problem here was not really anything to do with the above but > rather that ipa-client-install is flaky and can fail when running it a > few seconds later it succeeds. Since I am provisioning multiple > systems at a time in a script, it was not clearly obvious to me that it > was failing. What is "flaky" about it? > And so when ipa-client-install flakes out, of course what is left is > the previous instance of the node in FreeIPA complete with the previous > instance's SSH keys. Without any details it's hard to say what is going on. Having a side-by-side of an unsuccessful install log and a successful install log a few seconds later would be very helpful. rob From john.obaterspok at gmail.com Thu Nov 5 16:07:11 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Thu, 5 Nov 2015 17:07:11 +0100 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: <20151105112642.GN8374@redhat.com> References: <563793D9.8050508@redhat.com> <563865D3.5030305@redhat.com> <20151105112642.GN8374@redhat.com> Message-ID: 2015-11-05 12:26 GMT+01:00 Alexander Bokovoy : > On Thu, 05 Nov 2015, John Obaterspok wrote: > >> Hi, >> >> I waited a couple of days and when "dnf list freeipa-server >> --releasever=23" said 4.2.3 I hit the upgrade. Unfortunately I noticed to >> late that I received 4.2.2 during "dnf system-upgrade". >> >> Any ideas how to get it going again? Or is it easier to start from scratch >> if I only have ~ 10 IPA clients? >> > Did you already upgrade to 4.2.3? Make sure you have > pki-core-10.2.6-12.fc23 and freeipa 4.2.3-1.fc23, run > ipa-server-upgrade. It should be able to recover. > > Hi Alexander, Untfortunatly not, it's not able to recover: ##### rpm -q pki-base freeipa-server pki-base-10.2.6-12.fc23.noarch freeipa-server-4.2.3-1.fc23.x86_64 (Note I have pki-base, not pki-core... but I guess that was what you ment) ##### ipa-server-upgrade session memcached servers not running Missing version: no platform stored Upgrading IPA: [1/8]: saving configuration [2/8]: disabling listeners [3/8]: enabling DS global lock [4/8]: starting directory server [error] CalledProcessError: Command ''/bin/systemctl' 'start' 'dirsrv at MY-LAN.service'' returned non-zero exit status 1 [cleanup]: stopping directory server [cleanup]: restoring configuration IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command ''/bin/systemctl' 'start' 'dirsrv at MY-LAN.service'' returned non-zero exit status 1 ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] - Cannot find parent attribute type "ipaPublicKey" ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-MY-LAN/schema/99user.ldif (lineno: 1) is invalid, error code 21 ( ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] dse - Please edit the file to correct the reported problems and then restart the server. systemd[1]: dirsrv at MY-LAN.service: Control process exited, code=exited status=1 ##### 99user.ldif first lines has the following dn: cn=schema objectclass: top objectclass: ldapSubentry objectclass: subschema cn: schema aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) modifiersname: cn=Directory Manager Any ideas? -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Nov 5 23:36:06 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 5 Nov 2015 15:36:06 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <563B6CF9.4020501@redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> Message-ID: Thanks. After the changes, most things seem to be in order. I see two orange flags though: Secure Client-Initiated Renegotiation*Supported* *DoS DANGER* (more info )Session resumption (caching)*No (IDs assigned but not accepted)* Are these relevant/serious ? Can they be mitigated ? On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden wrote: > Prasun Gera wrote: > > Yes, that's what I was planning to do. i.e. Convert cipher names from > > SSL to NSS. I wasn't sure about the other settings though. Is there an > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there > > equivalent configs for HSTS on the mozilla page? Does NSS allow using > > generated DH parameters instead of standard ones ? For SSL, the > > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters > > "{path to dhparams.pem}"' after generating the params. > > NSS does not let the user specify cipher order. It uses its own internal > sorting from strongest to weakest. > > HSTS is a header and not dependent upon SSL provider. > > mod_nss doesn't support DH ciphers. > > rob > > > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale > > wrote: > > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > > Thanks for the ticket information. I would still be interested in > > > configuring mod_nss properly (irrespective of whether the certs > are ipa > > > generated or 3rd party). These are the worrying notes from ssllabs > test: > > > > > > The server supports only older protocols, but not the current best > TLS 1.2. > > > Grade capped to C. > > > This server accepts the RC4 cipher, which is weak. Grade capped to > B. > > > The server does not support Forward Secrecy with the reference > browsers. > > > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > > starting point. See also the "Cipher names correspondence table" on > > the same page for translating it to cipher names understood by NSS > > to construct a valid setting for the `NSSCipherSuite' directive. > > > > [1] > > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > > Cheers, > > Fraser > > > > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > wrote: > > > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible > > publicly. > > > > I'm > > > > > using a stock configuration which uses the certs signed by > > ipa's CA for > > > > the > > > > > webui. This is mostly for convenience since it manages renewals > > > > seamlessly. > > > > > This, however, requires users to add the CA as trusted to their > > > > browsers. A > > > > > promising alternative to this is https://letsencrypt.org/, > > which issues > > > > > browser trusted certs, and will manage auto renewals too (in > > the future). > > > > > As a feature request, it would be nice to have closer > > integration between > > > > > ipa and the letsencrypt client which would make managing certs > > simple. > > > > I'm > > > > > about to set this up manually right now using the external ssl > > certs > > > > guide. > > > > > > > > > Let's Encrypt is on our radar. I like the idea of being able to > > > > install FreeIPA with publicly-trusted certs for HTTP and LDAP > from > > > > the beginning. This would require some work in > ipa-server-install > > > > in addition to certmonger support and a good, stable Let's > Encrypt / > > > > ACME client implementation for Apache on Fedora. > > > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common > activity > > > > so I filed a ticket: > https://fedorahosted.org/freeipa/ticket/5431 > > > > > > > > Cheers, > > > > Fraser > > > > > > > > > Secondly, since the webui uses mod_nss, how would one set it > > up to prefer > > > > > security over compatibility with older clients ? The vast > > majority of > > > > > documentation online (for eg. > > > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > > > about > > > > > mod_ssl and I think the configuration doesn't transfer > directly to > > > > mod_nss. > > > > > Since this is the only web facing component, I would like to > > set it up to > > > > > use stringent requirements. Right now, a test on > > > > > https://www.ssllabs.com/ssltest/ and > > https://weakdh.org/sysadmin.html > > > > > identifies > > > > > several issues. Since these things are not really my area of > > expertise, I > > > > > would like some documentation regarding this. Also, would > manually > > > > > modifying any of the config files be overwritten by a yum > update ? > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcnt at use.startmail.com Thu Nov 5 23:57:48 2015 From: jcnt at use.startmail.com (jcnt at use.startmail.com) Date: Thu, 5 Nov 2015 18:57:48 -0500 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: <563BA5D2.5020904@redhat.com> References: <563BA5D2.5020904@redhat.com> Message-ID: On Thursday, November 5, 2015 1:54 PM, Rob Crittenden wrote: > jcnt at use.startmail.com wrote: >> Hello everyone, >> >> I initially followed freeipa NFS documentation for setting up external >> stand alone NFS server >> >> ipa host-add mickey.corp.example.org >> ipa service-add nfs/mickey.corp.example.org >> ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org >> -k /tmp/nfs.keytab >> >> uploaded keytab to NFS server and all appeared to work just fine: >> >> mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf > > Why are you using a custom krb5.conf? NFS server is a network appliance. It automatically creates /etc/nfs/krb5.conf based on nfs keytab provided. > >> mickey> kinit admin >> Password for admin at CORP.EXAMPLE.ORG: XXXXXXX >> mickey> klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at CORP.EXAMPLE.ORG >> >> Valid starting Expires Service principal >> 05/16/2015 18:17:00 05/17/2015 18:16:50 >> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >> mickey> kinit -k -t /etc/nfs/krb5.keytab >> nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >> mickey> klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >> >> Valid starting Expires Service principal >> 05/16/2015 23:48:14 05/17/2015 23:48:13 >> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >> mickey> >> >> However, I learned hard way (NFS stopped working) that ipa-getkeytab >> issues ticket with a default timeout of 3 months. > > keytabs don't time out. What made you think it has a 3-month validity > period? Well, network appliance tech support told me that "authentication key being expired". Are you saying that keytab should never need to be updated on NFS server? >> >> I repeated ipa-getkeytab and got: >> >> mickey> kinit -k -t /etc/nfs/krb5.keytab >> kinit: Keytab contains no suitable keys for >> host/mickey.corp.example.org at CORP.EXAMPLE.ORG while getting initial >> credentials >> mickey> klist -k -t /etc/nfs/krb5.keytab >> Keytab name: FILE:/etc/nfs/krb5.keytab >> KVNO Timestamp Principal >> ---- ------------------- >> ------------------------------------------------------ >> 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >> 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >> 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >> 5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG > > You used the right command earlier: > > # kinit -k -t /etc/nfs/krb5.keytab > nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG Opps, found the problem, at least on kinit part, principal should be specified on command line: #kinit -k -t /etc/nfs/krb5.keytab \ nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG # > >> When client tries to mount: >> >> # mount -vvv -o sec=krb5 mickey:/volume1/homes /mnt >> mount.nfs: timeout set for Thu Nov 5 11:41:39 2015 >> mount.nfs: trying text-based options >> 'sec=krb5,vers=4,addr=192.168.26.2,clientaddr=192.168.26.31' >> mount.nfs: mount(2): Invalid argument >> mount.nfs: an incorrect mount option was specified >> >> Not much information available... >> >> Any NFS experts out here? > > The NFS server may have more info. That is a network appliance, I'll have to try to manually add debug options to NFS components. But client is an IPA domain member, kerberos logins are working just fine - is it sufficient to conclude that host is in good shape? Thanks you. Josh. From rcritten at redhat.com Fri Nov 6 04:52:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Nov 2015 23:52:32 -0500 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> Message-ID: <563C3210.40600@redhat.com> Prasun Gera wrote: > Thanks. After the changes, most things seem to be in order. I see two > orange flags though: > > Secure Client-Initiated Renegotiation *Supported* *DoS DANGER* (more > info > ) Renegotiation is required for the CA so you need to leave this enabled. > Session resumption (caching) *No (IDs assigned but not accepted)* I'll need to look at this in more detail. At worst it would slow new connection performance slightly as it means every connection requires a full SSL/TLS handshake. I don't think it's a show-stopper. rob > > Are these relevant/serious ? Can they be mitigated ? > > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden > wrote: > > Prasun Gera wrote: > > Yes, that's what I was planning to do. i.e. Convert cipher names from > > SSL to NSS. I wasn't sure about the other settings though. Is there an > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there > > equivalent configs for HSTS on the mozilla page? Does NSS allow using > > generated DH parameters instead of standard ones ? For SSL, the > > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters > > "{path to dhparams.pem}"' after generating the params. > > NSS does not let the user specify cipher order. It uses its own internal > sorting from strongest to weakest. > > HSTS is a header and not dependent upon SSL provider. > > mod_nss doesn't support DH ciphers. > > rob > > > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale > > >> wrote: > > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > > Thanks for the ticket information. I would still be interested in > > > configuring mod_nss properly (irrespective of whether the certs are ipa > > > generated or 3rd party). These are the worrying notes from ssllabs test: > > > > > > The server supports only older protocols, but not the current best TLS 1.2. > > > Grade capped to C. > > > This server accepts the RC4 cipher, which is weak. Grade capped to B. > > > The server does not support Forward Secrecy with the reference browsers. > > > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > > starting point. See also the "Cipher names correspondence table" on > > the same page for translating it to cipher names understood by NSS > > to construct a valid setting for the `NSSCipherSuite' directive. > > > > [1] > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > > Cheers, > > Fraser > > > > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > >> wrote: > > > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > accessible > > publicly. > > > > I'm > > > > > using a stock configuration which uses the certs signed by > > ipa's CA for > > > > the > > > > > webui. This is mostly for convenience since it manages > renewals > > > > seamlessly. > > > > > This, however, requires users to add the CA as trusted > to their > > > > browsers. A > > > > > promising alternative to this is https://letsencrypt.org/, > > which issues > > > > > browser trusted certs, and will manage auto renewals too (in > > the future). > > > > > As a feature request, it would be nice to have closer > > integration between > > > > > ipa and the letsencrypt client which would make managing > certs > > simple. > > > > I'm > > > > > about to set this up manually right now using the > external ssl > > certs > > > > guide. > > > > > > > > > Let's Encrypt is on our radar. I like the idea of being > able to > > > > install FreeIPA with publicly-trusted certs for HTTP and > LDAP from > > > > the beginning. This would require some work in > ipa-server-install > > > > in addition to certmonger support and a good, stable Let's > Encrypt / > > > > ACME client implementation for Apache on Fedora. > > > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common > activity > > > > so I filed a ticket: > https://fedorahosted.org/freeipa/ticket/5431 > > > > > > > > Cheers, > > > > Fraser > > > > > > > > > Secondly, since the webui uses mod_nss, how would one set it > > up to prefer > > > > > security over compatibility with older clients ? The vast > > majority of > > > > > documentation online (for eg. > > > > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > > > about > > > > > mod_ssl and I think the configuration doesn't transfer > directly to > > > > mod_nss. > > > > > Since this is the only web facing component, I would like to > > set it up to > > > > > use stringent requirements. Right now, a test on > > > > > https://www.ssllabs.com/ssltest/ and > > https://weakdh.org/sysadmin.html > > > > > identifies > > > > > several issues. Since these things are not really my area of > > expertise, I > > > > > would like some documentation regarding this. Also, > would manually > > > > > modifying any of the config files be overwritten by a > yum update ? > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > From ftweedal at redhat.com Fri Nov 6 05:23:17 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 6 Nov 2015 15:23:17 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <563C3210.40600@redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> Message-ID: <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > Prasun Gera wrote: > > Thanks. After the changes, most things seem to be in order. I see two > > orange flags though: > > > > Secure Client-Initiated Renegotiation *Supported* *DoS DANGER* (more > > info > > ) > > Renegotiation is required for the CA so you need to leave this enabled. > > > Session resumption (caching) *No (IDs assigned but not accepted)* > > I'll need to look at this in more detail. At worst it would slow new > connection performance slightly as it means every connection requires a > full SSL/TLS handshake. I don't think it's a show-stopper. > Definitely not a show-stopper. The main reason this is an "orange" alert in SSLLabs is because the server is assigning Session IDs but then ignoring them; although confusing it is a fairly common default behaviour and doesn't cause any issues with compliant client implementation > rob > > > > > Are these relevant/serious ? Can they be mitigated ? > > > > > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden > > wrote: > > > > Prasun Gera wrote: > > > Yes, that's what I was planning to do. i.e. Convert cipher names from > > > SSL to NSS. I wasn't sure about the other settings though. Is there an > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there > > > equivalent configs for HSTS on the mozilla page? Does NSS allow using > > > generated DH parameters instead of standard ones ? For SSL, the > > > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters > > > "{path to dhparams.pem}"' after generating the params. > > > > NSS does not let the user specify cipher order. It uses its own internal > > sorting from strongest to weakest. > > > > HSTS is a header and not dependent upon SSL provider. > > > > mod_nss doesn't support DH ciphers. > > > > rob > > > > > > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale > > > >> wrote: > > > > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > > > Thanks for the ticket information. I would still be interested in > > > > configuring mod_nss properly (irrespective of whether the certs are ipa > > > > generated or 3rd party). These are the worrying notes from ssllabs test: > > > > > > > > The server supports only older protocols, but not the current best TLS 1.2. > > > > Grade capped to C. > > > > This server accepts the RC4 cipher, which is weak. Grade capped to B. > > > > The server does not support Forward Secrecy with the reference browsers. > > > > > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > > > starting point. See also the "Cipher names correspondence table" on > > > the same page for translating it to cipher names understood by NSS > > > to construct a valid setting for the `NSSCipherSuite' directive. > > > > > > [1] > > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > > > > Cheers, > > > Fraser > > > > > > > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > > > >> wrote: > > > > > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote: > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > > accessible > > > publicly. > > > > > I'm > > > > > > using a stock configuration which uses the certs signed by > > > ipa's CA for > > > > > the > > > > > > webui. This is mostly for convenience since it manages > > renewals > > > > > seamlessly. > > > > > > This, however, requires users to add the CA as trusted > > to their > > > > > browsers. A > > > > > > promising alternative to this is https://letsencrypt.org/, > > > which issues > > > > > > browser trusted certs, and will manage auto renewals too (in > > > the future). > > > > > > As a feature request, it would be nice to have closer > > > integration between > > > > > > ipa and the letsencrypt client which would make managing > > certs > > > simple. > > > > > I'm > > > > > > about to set this up manually right now using the > > external ssl > > > certs > > > > > guide. > > > > > > > > > > > Let's Encrypt is on our radar. I like the idea of being > > able to > > > > > install FreeIPA with publicly-trusted certs for HTTP and > > LDAP from > > > > > the beginning. This would require some work in > > ipa-server-install > > > > > in addition to certmonger support and a good, stable Let's > > Encrypt / > > > > > ACME client implementation for Apache on Fedora. > > > > > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common > > activity > > > > > so I filed a ticket: > > https://fedorahosted.org/freeipa/ticket/5431 > > > > > > > > > > Cheers, > > > > > Fraser > > > > > > > > > > > Secondly, since the webui uses mod_nss, how would one set it > > > up to prefer > > > > > > security over compatibility with older clients ? The vast > > > majority of > > > > > > documentation online (for eg. > > > > > > > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is > > > > > about > > > > > > mod_ssl and I think the configuration doesn't transfer > > directly to > > > > > mod_nss. > > > > > > Since this is the only web facing component, I would like to > > > set it up to > > > > > > use stringent requirements. Right now, a test on > > > > > > https://www.ssllabs.com/ssltest/ and > > > https://weakdh.org/sysadmin.html > > > > > > identifies > > > > > > several issues. Since these things are not really my area of > > > expertise, I > > > > > > would like some documentation regarding this. Also, > > would manually > > > > > > modifying any of the config files be overwritten by a > > yum update ? > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > From schogan at us.ibm.com Fri Nov 6 07:21:29 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Fri, 6 Nov 2015 00:21:29 -0700 Subject: [Freeipa-users] Can't contact LDAP Server Message-ID: <201511060721.tA67LcEG009728@d01av01.pok.ibm.com> Hi All, We are having an issue where a client is showing sssd eatting up 100% cpu and cannot log into it via ssh. IE.. trying to ssh to it just hangs an never prompts for password. We have to get to the box from the console at that point. Top output on client 2365 root -30 0 89600 79m 18m R 124.5 0.0 22:15.22 rmcd 2627 root 20 0 159m 27m 18m R 100.0 0.0 10:40.98 sssd_be 92718 root 20 0 159m 11m 2560 R 98.8 0.0 0:13.65 sssd_be The sssd logs on the client in question is showing: tail -f sssd_ssh.log (Wed Nov 4 09:29:30 2015) [sssd[ssh]] [ssh_dp_reconnect_init] (0x0010): Could not reconnect to domain.name provider. (Wed Nov 4 09:30:00 2015) [sssd[ssh]] [ssh_dp_reconnect_init] (0x0010): Could not reconnect to domain.name provider. (Wed Nov 4 09:30:30 2015) [sssd[ssh]] [ssh_dp_reconnect_init] (0x0010): Could not reconnect to domain.name provider. (Wed Nov 4 09:31:30 2015) [sssd[ssh]] [dp_id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply] The Client is running: Red Hat Enterprise Linux Server release 6.6 (Santiago) sssd-ipa-1.11.6-30.el6_6.4.ppc64 ipa-client-3.0.0-42.el6.ppc64 I have been looking into the logs on our IPA server and found this but not sure what to make of it as the dirsrv is on the IPA server and if it is even related to the client issue. /var/log/dirsrv/slapd-DOMAIN-LOCAL 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 107 (Transport endpoint is not connected) /var/log/dirsrv/slapd-PKI-IPA shows: slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) IPA server is running: ipa-server-3.0.0-47.el6.x86_64 Red Hat Enterprise Linux Server release 6.7 (Santiago) sssd-ipa-1.12.4-47.el6.x86_64 ipa-client-3.0.0-47.el6.x86_64 ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING It seems to be sporadic as the client was working fine under a heavy application load(application ID is in IPA) and once the load test was over sssd started causing the DOS. We have seen this happen a few times over the past few days and does not always happen after a load test is complete. I have been shutting down sssd and restarting it to clear it up and allow ssh logins. Is the version difference between the ipa client/sssd and server an issue and any ideas on where to go next? Sean Hogan Security Engineer CISSP, RHSA, CCNA Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan at us.ibm.com | Tel 919 486 1397 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07327181.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07459251.gif Type: image/gif Size: 1650 bytes Desc: not available URL: From jhrozek at redhat.com Fri Nov 6 08:19:24 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 6 Nov 2015 09:19:24 +0100 Subject: [Freeipa-users] Can't contact LDAP Server In-Reply-To: <201511060721.tA67LcEG009728@d01av01.pok.ibm.com> References: <201511060721.tA67LcEG009728@d01av01.pok.ibm.com> Message-ID: <20151106081924.GN3242@hendrix> On Fri, Nov 06, 2015 at 12:21:29AM -0700, Sean Hogan wrote: > > > Hi All, > > We are having an issue where a client is showing sssd eatting up 100% > cpu and cannot log into it via ssh. IE.. trying to ssh to it just hangs an > never prompts for password. We have to get to the box from the console at > that point. > > Top output on client > 2365 root -30 0 89600 79m 18m R 124.5 0.0 22:15.22 rmcd > 2627 root 20 0 159m 27m 18m R 100.0 0.0 10:40.98 sssd_be > 92718 root 20 0 159m 11m 2560 R 98.8 0.0 0:13.65 sssd_be Do you have one domain or two configured on the client? If only one, then the two sssd_be processes would indicate sssd_be was restarted but > > The sssd logs on the client in question is showing: More interesting info would be in the domain log or monitor's sssd.log pstack of sssd_be when sssd_be is looping would also be helpful. From abokovoy at redhat.com Fri Nov 6 08:24:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Nov 2015 10:24:53 +0200 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: References: <563BA5D2.5020904@redhat.com> Message-ID: <20151106082453.GV8374@redhat.com> On Thu, 05 Nov 2015, jcnt at use.startmail.com wrote: >On Thursday, November 5, 2015 1:54 PM, Rob Crittenden wrote: >> jcnt at use.startmail.com wrote: >>> Hello everyone, >>> >>> I initially followed freeipa NFS documentation for setting up external >>> stand alone NFS server >>> >>> ipa host-add mickey.corp.example.org >>> ipa service-add nfs/mickey.corp.example.org >>> ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org >>> -k /tmp/nfs.keytab >>> >>> uploaded keytab to NFS server and all appeared to work just fine: >>> >>> mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf >> >> Why are you using a custom krb5.conf? >NFS server is a network appliance. It automatically creates /etc/nfs/krb5.conf based on nfs keytab provided. > >> >>> mickey> kinit admin >>> Password for admin at CORP.EXAMPLE.ORG: XXXXXXX >>> mickey> klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: admin at CORP.EXAMPLE.ORG >>> >>> Valid starting Expires Service principal >>> 05/16/2015 18:17:00 05/17/2015 18:16:50 >>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >>> mickey> kinit -k -t /etc/nfs/krb5.keytab >>> nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >>> mickey> klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >>> >>> Valid starting Expires Service principal >>> 05/16/2015 23:48:14 05/17/2015 23:48:13 >>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >>> mickey> >>> >>> However, I learned hard way (NFS stopped working) that ipa-getkeytab >>> issues ticket with a default timeout of 3 months. >> >> keytabs don't time out. What made you think it has a 3-month validity >> period? >Well, network appliance tech support told me that "authentication key being expired". >Are you saying that keytab should never need to be updated on NFS server? principal key != valid ticket. With the help of the principal's key you can get a ticket which is valid for some time. It needs to be renewed periodically. In case of FreeIPA as KDC the default validity of the ticket is 24 hours. Kerberos principal keys, on other hand, only expire if there is a password policy associated with them. For service principals you create with 'ipa service-add' there is no expiration associated with the key that is generated with 'ipa-getkeytab' as keys are generated randomly and long enough to be seen as strong. User principals have password policy associated with them and expire normally (90 days is the default password policy expiration time). Your workflow should be something like this (using IPA CLI as an example here): 1. Create a service with 'ipa service-add' 2. Associate a key with a service with 'ipa-getkeytab' and store it in a keytab -- either directly on the server where service is running or on any other IPA client. 3. Deliver the keytab from step (2) to a server where it should be if needed. In case of clustered configuration deliver the keytab to all cluster nodes which will be operating as the service. Do not run 'ipa-getkeytab' multiple times as each run invalidates previously obtained keytab. 4. Use the keytab to kinit and obtain initial ticket granting ticket (TGT) for the service principal periodically. This either has to be supported by an application itself or run with a wrapper that kinits periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to perform automatic renewal, this is much cleaner way of doing it. If your NAS appliance has issues like below it only says that NFS server side did not accept your configuration. Thus, you need to look into the NAS appliance logs to say what is wrong there. -- / Alexander Bokovoy From pspacek at redhat.com Fri Nov 6 08:27:20 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 Nov 2015 09:27:20 +0100 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: <20151106082453.GV8374@redhat.com> References: <563BA5D2.5020904@redhat.com> <20151106082453.GV8374@redhat.com> Message-ID: <563C6468.5030608@redhat.com> On 6.11.2015 09:24, Alexander Bokovoy wrote: > On Thu, 05 Nov 2015, jcnt at use.startmail.com wrote: >> On Thursday, November 5, 2015 1:54 PM, Rob Crittenden >> wrote: >>> jcnt at use.startmail.com wrote: >>>> Hello everyone, >>>> >>>> I initially followed freeipa NFS documentation for setting up external >>>> stand alone NFS server >>>> >>>> ipa host-add mickey.corp.example.org >>>> ipa service-add nfs/mickey.corp.example.org >>>> ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org >>>> -k /tmp/nfs.keytab >>>> >>>> uploaded keytab to NFS server and all appeared to work just fine: >>>> >>>> mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf >>> >>> Why are you using a custom krb5.conf? >> NFS server is a network appliance. It automatically creates >> /etc/nfs/krb5.conf based on nfs keytab provided. >> >>> >>>> mickey> kinit admin >>>> Password for admin at CORP.EXAMPLE.ORG: XXXXXXX >>>> mickey> klist >>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>> Default principal: admin at CORP.EXAMPLE.ORG >>>> >>>> Valid starting Expires Service principal >>>> 05/16/2015 18:17:00 05/17/2015 18:16:50 >>>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >>>> mickey> kinit -k -t /etc/nfs/krb5.keytab >>>> nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >>>> mickey> klist >>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>> Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG >>>> >>>> Valid starting Expires Service principal >>>> 05/16/2015 23:48:14 05/17/2015 23:48:13 >>>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG >>>> mickey> >>>> >>>> However, I learned hard way (NFS stopped working) that ipa-getkeytab >>>> issues ticket with a default timeout of 3 months. >>> >>> keytabs don't time out. What made you think it has a 3-month validity >>> period? >> Well, network appliance tech support told me that "authentication key being >> expired". >> Are you saying that keytab should never need to be updated on NFS server? > principal key != valid ticket. With the help of the principal's key you > can get a ticket which is valid for some time. It needs to be renewed > periodically. In case of FreeIPA as KDC the default validity of the > ticket is 24 hours. Kerberos principal keys, on other hand, only expire > if there is a password policy associated with them. For service > principals you create with 'ipa service-add' there is no expiration > associated with the key that is generated with 'ipa-getkeytab' as > keys are generated randomly and long enough to be seen as strong. User > principals have password policy associated with them and expire normally > (90 days is the default password policy expiration time). > > Your workflow should be something like this (using IPA CLI as an example > here): > 1. Create a service with 'ipa service-add' > 2. Associate a key with a service with 'ipa-getkeytab' and store it in a > keytab -- either directly on the server where service is running or on > any other IPA client. > 3. Deliver the keytab from step (2) to a server where it should be if > needed. In case of clustered configuration deliver the keytab to all > cluster nodes which will be operating as the service. > > Do not run 'ipa-getkeytab' multiple times as each run invalidates > previously obtained keytab. > > 4. Use the keytab to kinit and obtain initial ticket granting ticket > (TGT) for the service principal periodically. This either has to be > supported by an application itself or run with a wrapper that kinits > periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to > perform automatic renewal, this is much cleaner way of doing it. > > If your NAS appliance has issues like below it only says that NFS server > side did not accept your configuration. Thus, you need to look into the > NAS appliance logs to say what is wrong there. In other words, if $ kinit -k -t /etc/nfs/krb5.keytab nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG is working then the problem is somewhere in appliance config. -- Petr^2 Spacek From jhrozek at redhat.com Fri Nov 6 08:34:11 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 6 Nov 2015 09:34:11 +0100 Subject: [Freeipa-users] Can't contact LDAP Server In-Reply-To: <20151106081924.GN3242@hendrix> References: <201511060721.tA67LcEG009728@d01av01.pok.ibm.com> <20151106081924.GN3242@hendrix> Message-ID: <20151106083411.GO3242@hendrix> On Fri, Nov 06, 2015 at 09:19:24AM +0100, Jakub Hrozek wrote: > On Fri, Nov 06, 2015 at 12:21:29AM -0700, Sean Hogan wrote: > > > > > > Hi All, > > > > We are having an issue where a client is showing sssd eatting up 100% > > cpu and cannot log into it via ssh. IE.. trying to ssh to it just hangs an > > never prompts for password. We have to get to the box from the console at > > that point. > > > > Top output on client > > 2365 root -30 0 89600 79m 18m R 124.5 0.0 22:15.22 rmcd > > 2627 root 20 0 159m 27m 18m R 100.0 0.0 10:40.98 sssd_be > > 92718 root 20 0 159m 11m 2560 R 98.8 0.0 0:13.65 sssd_be > > Do you have one domain or two configured on the client? If only one, > then the two sssd_be processes would indicate sssd_be was restarted but > oops, restarted but the old one is still around. From mkosek at redhat.com Fri Nov 6 08:50:41 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 6 Nov 2015 09:50:41 +0100 Subject: [Freeipa-users] FreeIPA Server with ECC certificate in LDAPS (389DS) In-Reply-To: References: Message-ID: <563C69E1.8050007@redhat.com> On 11/05/2015 02:39 PM, Marat Vyshegorodtsev wrote: > Hi! > > I've been fighting for the past week with FreeIPA and trying to make > it work with my own CA certificate that is ECDSA_SHA256. > > Even though I somehow fixed /etc/httpd/conf.d/nss.conf to make it work > (basically added correct NSSCipherSuite), LDAP (389DS) is a tough nut. > > The command I used is: > > ipa-server-install --mkhomedir --hostname 'ipa.mydomain.com' --realm > MYDOMAIN.COM --domain mydomain.com --ds-password 'DS_PASSWORD_HERE' > --admin-password 'ADMIN_PASSWORD_HERE' --no-ntp --unattended > --no-host-dns --dirsrv-cert-file /etc/ipa/ipa.p12 --http-cert-file > /etc/ipa/ipa.p12 --dirsrv-pin 'PIN_FOR_CERT' --http-pin 'PIN_FOR_CERT' > --ca-cert-file /etc/ipa/myownca.pem > > In this case, installation fails at the following step: > Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' > 'ipa.rpay.us' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' > '/var/lib/ipa/tmp5KkCae' '-T' '/var/lib/ipa/tmpTC27Ap' > 'uid=admin,cn=users,cn=accounts,dc=rpay,dc=us'' returned non-zero exit > status 1 > > In /var/log/ipaserver-install.log I see a message: > DEBUG stderr=ldap_start_tls: Protocol error (2) > additional info: SSL not supported by this server. > > Basically, LDAP is broken now (it doesn't allow connecting without -ZZ > flag, and fails with it, since TLS is misconfigured at this point). > > What actually happens, LDAP gets configured to use RSA as a key > exchange algorithm, and fails, since the cert is an ECC cert. > > In /var/log/dirsrv/slapd-MYDOMAIN-COM/errors you can see: > [05/Nov/2015:12:22:36 +0000] - SSL alert: ConfigSecureServer: Server > key/certificate is bad for cert FreeIPA of family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -12200 > - The certificate provided cannot be used with the selected key > exchange algorithm.) > > This is configured by ipaserver/install/dsinstance.py under def __enable_ssl: > > entry = conn.make_entry( > DN(('cn', 'RSA'), ('cn', 'encryption'), ('cn', 'config')), > objectclass=["top", "nsEncryptionModule"], > cn=["RSA"], > nsSSLPersonalitySSL=[self.nickname], > nsSSLToken=["internal (software)"], > nsSSLActivation=["on"], > ) > conn.add_entry(entry) > > My question is, is it possible to replace RSA with ECDSA here? If so, > what parameters should I pass to LDAP? Honza or Ludwig, do you know? This is certainly an uncharted territory, you are the first person I know about trying to install FreeIPA CA-less with ECC certificate. There is a ticket to get ECC support in PKI (i.e. not CA-less), but it was not completed yet: https://fedorahosted.org/freeipa/ticket/3951 > > If this is fixable, can someone add autodetect of the type of the > certificate and enable appropriate algorithms in LDAP and Apache? > > Best regards, > Marat Vyshegorodtsev > From john.obaterspok at gmail.com Fri Nov 6 08:18:06 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Fri, 6 Nov 2015 09:18:06 +0100 Subject: [Freeipa-users] IMPORTANT: FreeIPA upgrade broken in Fedora 23 In-Reply-To: References: <563793D9.8050508@redhat.com> <563865D3.5030305@redhat.com> <20151105112642.GN8374@redhat.com> Message-ID: 2015-11-05 17:07 GMT+01:00 John Obaterspok : > > > 2015-11-05 12:26 GMT+01:00 Alexander Bokovoy : > >> On Thu, 05 Nov 2015, John Obaterspok wrote: >> >>> Hi, >>> >>> I waited a couple of days and when "dnf list freeipa-server >>> --releasever=23" said 4.2.3 I hit the upgrade. Unfortunately I noticed to >>> late that I received 4.2.2 during "dnf system-upgrade". >>> >>> Any ideas how to get it going again? Or is it easier to start from >>> scratch >>> if I only have ~ 10 IPA clients? >>> >> Did you already upgrade to 4.2.3? Make sure you have >> pki-core-10.2.6-12.fc23 and freeipa 4.2.3-1.fc23, run >> ipa-server-upgrade. It should be able to recover. >> >> > Hi Alexander, > > Untfortunatly not, it's not able to recover: > > ##### rpm -q pki-base freeipa-server > pki-base-10.2.6-12.fc23.noarch > freeipa-server-4.2.3-1.fc23.x86_64 > > (Note I have pki-base, not pki-core... but I guess that was what you ment) > > ##### ipa-server-upgrade > session memcached servers not running > Missing version: no platform stored > Upgrading IPA: > [1/8]: saving configuration > [2/8]: disabling listeners > [3/8]: enabling DS global lock > [4/8]: starting directory server > [error] CalledProcessError: Command ''/bin/systemctl' 'start' > 'dirsrv at MY-LAN.service'' returned non-zero exit status 1 > [cleanup]: stopping directory server > [cleanup]: restoring configuration > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command > ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > CalledProcessError: Command ''/bin/systemctl' 'start' > 'dirsrv at MY-LAN.service'' returned non-zero exit status 1 > > ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] - Cannot find parent > attribute type "ipaPublicKey" > ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] dse_read_one_file - The entry > cn=schema in file /etc/dirsrv/slapd-MY-LAN/schema/99user.ldif (lineno: 1) > is invalid, error code 21 ( > ns-slapd[2083]: [05/Nov/2015:16:55:32 +0100] dse - Please edit the file to > correct the reported problems and then restart the server. > systemd[1]: dirsrv at MY-LAN.service: Control process exited, code=exited > status=1 > > ##### 99user.ldif first lines has the following > dn: cn=schema > objectclass: top > objectclass: ldapSubentry > objectclass: subschema > cn: schema > aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl > "anonymous, no acis"; allow (read, search, compare) userdn = > "ldap:///anyone";) > modifiersname: cn=Directory Manager > > > Any ideas? > > -- john > I just found https://fedoraproject.org/wiki/Common_F23_bugs#freeipa-upgrade-fail which allowed me to run freeipa-server-upgrade successfully. Just a note: It says "Find the entry (split across three lines) that starts attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey'" However, it's all on one line without spaces Then make sure the text you replace with don't have extra spaces. Should be DESC 'IPA... & ...1466.115.121... Thanks! -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From marat.vyshegorodtsev at gmail.com Fri Nov 6 09:24:17 2015 From: marat.vyshegorodtsev at gmail.com (Marat Vyshegorodtsev) Date: Fri, 06 Nov 2015 09:24:17 +0000 Subject: [Freeipa-users] FreeIPA Server with ECC certificate in LDAPS (389DS) In-Reply-To: <563C69E1.8050007@redhat.com> References: <563C69E1.8050007@redhat.com> Message-ID: Actually, looking at the source code of 389DS it is impossible. I gave up. http://fossies.org/linux/389-ds-base/ldap/servers/slapd/ssl.c (see screenshot) Only RSA and some mysterious Fortezza are allowed. NSS' SSL_ConfigSecureServer actually does support kt_dh, not sure if it applies to ECDH as well. I think working around 389DS' SSL code would be harder than just wrapping port 389 into stunnel, but FreeIPA installer doesn't allow the port 636 to be used by anyone else. Seriously, can we just drop Apache+mod_nss and LDAP+libnss? Instead, have the web GUI wrapped into nginx and LDAP into stunnel? One may argue that there won't be single sign-on, because Kerberos, but is anyone seriously using IE anymore? As you might have seen from a parallel thread, NSS does a terrible job with sslabs by default. It is almost 2016, TLSv1.3 will be released soon, but it barely had support of TLSv1.2. As for now, I suggest writing it in docs and add a check to ipa CLI tools not to allow ECC certs. Marat 2015?11?6?(?) 17:50 Martin Kosek : > On 11/05/2015 02:39 PM, Marat Vyshegorodtsev wrote: > > Hi! > > > > I've been fighting for the past week with FreeIPA and trying to make > > it work with my own CA certificate that is ECDSA_SHA256. > > > > Even though I somehow fixed /etc/httpd/conf.d/nss.conf to make it work > > (basically added correct NSSCipherSuite), LDAP (389DS) is a tough nut. > > > > The command I used is: > > > > ipa-server-install --mkhomedir --hostname 'ipa.mydomain.com' --realm > > MYDOMAIN.COM --domain mydomain.com --ds-password 'DS_PASSWORD_HERE' > > --admin-password 'ADMIN_PASSWORD_HERE' --no-ntp --unattended > > --no-host-dns --dirsrv-cert-file /etc/ipa/ipa.p12 --http-cert-file > > /etc/ipa/ipa.p12 --dirsrv-pin 'PIN_FOR_CERT' --http-pin 'PIN_FOR_CERT' > > --ca-cert-file /etc/ipa/myownca.pem > > > > In this case, installation fails at the following step: > > Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' > > 'ipa.rpay.us' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' > > '/var/lib/ipa/tmp5KkCae' '-T' '/var/lib/ipa/tmpTC27Ap' > > 'uid=admin,cn=users,cn=accounts,dc=rpay,dc=us'' returned non-zero exit > > status 1 > > > > In /var/log/ipaserver-install.log I see a message: > > DEBUG stderr=ldap_start_tls: Protocol error (2) > > additional info: SSL not supported by this server. > > > > Basically, LDAP is broken now (it doesn't allow connecting without -ZZ > > flag, and fails with it, since TLS is misconfigured at this point). > > > > What actually happens, LDAP gets configured to use RSA as a key > > exchange algorithm, and fails, since the cert is an ECC cert. > > > > In /var/log/dirsrv/slapd-MYDOMAIN-COM/errors you can see: > > [05/Nov/2015:12:22:36 +0000] - SSL alert: ConfigSecureServer: Server > > key/certificate is bad for cert FreeIPA of family > > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -12200 > > - The certificate provided cannot be used with the selected key > > exchange algorithm.) > > > > This is configured by ipaserver/install/dsinstance.py under def > __enable_ssl: > > > > entry = conn.make_entry( > > DN(('cn', 'RSA'), ('cn', 'encryption'), ('cn', 'config')), > > objectclass=["top", "nsEncryptionModule"], > > cn=["RSA"], > > nsSSLPersonalitySSL=[self.nickname], > > nsSSLToken=["internal (software)"], > > nsSSLActivation=["on"], > > ) > > conn.add_entry(entry) > > > > My question is, is it possible to replace RSA with ECDSA here? If so, > > what parameters should I pass to LDAP? > > Honza or Ludwig, do you know? This is certainly an uncharted territory, > you are > the first person I know about trying to install FreeIPA CA-less with ECC > certificate. > > There is a ticket to get ECC support in PKI (i.e. not CA-less), but it was > not > completed yet: > https://fedorahosted.org/freeipa/ticket/3951 > > > > > If this is fixable, can someone add autodetect of the type of the > > certificate and enable appropriate algorithms in LDAP and Apache? > > > > Best regards, > > Marat Vyshegorodtsev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_1381.PNG Type: image/png Size: 96862 bytes Desc: not available URL: From abokovoy at redhat.com Fri Nov 6 11:50:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Nov 2015 13:50:04 +0200 Subject: [Freeipa-users] FreeIPA Server with ECC certificate in LDAPS (389DS) In-Reply-To: References: <563C69E1.8050007@redhat.com> Message-ID: <20151106115004.GW8374@redhat.com> On Fri, 06 Nov 2015, Marat Vyshegorodtsev wrote: >Actually, looking at the source code of 389DS it is impossible. > > >I gave up. > > >http://fossies.org/linux/389-ds-base/ldap/servers/slapd/ssl.c >(see screenshot) > > >Only RSA and some mysterious Fortezza are allowed. NSS' >SSL_ConfigSecureServer actually does support kt_dh, not sure if it applies >to ECDH as well. > >I think working around 389DS' SSL code would be harder than just wrapping >port 389 into stunnel, but FreeIPA installer doesn't allow the port 636 to >be used by anyone else. > >Seriously, can we just drop Apache+mod_nss and LDAP+libnss? Instead, have >the web GUI wrapped into nginx and LDAP into stunnel? > >One may argue that there won't be single sign-on, because Kerberos, but is >anyone seriously using IE anymore? How IE is relevant here? Are you stuck on Windows without real browsers? On port 389 we are using SASL GSSAPI which gives you both encryption and signing. Anyway, I think you are just steaming your frustration here. If you want constructive discussion, maybe let's start with filing a number of tickets to 389-ds and FreeIPA to support ECC certificates? Automating detection and enabling correct cipher types is certainly worth it. >As you might have seen from a parallel thread, NSS does a terrible job with >sslabs by default. It is almost 2016, TLSv1.3 will be released soon, but it >barely had support of TLSv1.2. >As for now, I suggest writing it in docs and add a check to ipa CLI tools >not to allow ECC certs. I'm getting A- from ssllabs checks for my server with RSA certificate and mod_nss, what I'm doing wrong? A- is mostly for lack of PFS and some certificate chain excess that I'm planning to fix soon. HTTP server signature: Apache/2.4.16 (Fedora) mod_auth_gssapi/1.3.1 mod_nss/2.4.16 NSS/3.19.3 Basic ECC PHP/5.6.14 mod_wsgi/4.4.8 Python/2.7.10 It is Fedora 22 with FreeIPA 4.2.2. >Marat > >2015?11?6?(?) 17:50 Martin Kosek : > >> On 11/05/2015 02:39 PM, Marat Vyshegorodtsev wrote: >> > Hi! >> > >> > I've been fighting for the past week with FreeIPA and trying to make >> > it work with my own CA certificate that is ECDSA_SHA256. >> > >> > Even though I somehow fixed /etc/httpd/conf.d/nss.conf to make it work >> > (basically added correct NSSCipherSuite), LDAP (389DS) is a tough nut. >> > >> > The command I used is: >> > >> > ipa-server-install --mkhomedir --hostname 'ipa.mydomain.com' --realm >> > MYDOMAIN.COM --domain mydomain.com --ds-password 'DS_PASSWORD_HERE' >> > --admin-password 'ADMIN_PASSWORD_HERE' --no-ntp --unattended >> > --no-host-dns --dirsrv-cert-file /etc/ipa/ipa.p12 --http-cert-file >> > /etc/ipa/ipa.p12 --dirsrv-pin 'PIN_FOR_CERT' --http-pin 'PIN_FOR_CERT' >> > --ca-cert-file /etc/ipa/myownca.pem >> > >> > In this case, installation fails at the following step: >> > Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' >> > 'ipa.rpay.us' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' >> > '/var/lib/ipa/tmp5KkCae' '-T' '/var/lib/ipa/tmpTC27Ap' >> > 'uid=admin,cn=users,cn=accounts,dc=rpay,dc=us'' returned non-zero exit >> > status 1 >> > >> > In /var/log/ipaserver-install.log I see a message: >> > DEBUG stderr=ldap_start_tls: Protocol error (2) >> > additional info: SSL not supported by this server. >> > >> > Basically, LDAP is broken now (it doesn't allow connecting without -ZZ >> > flag, and fails with it, since TLS is misconfigured at this point). >> > >> > What actually happens, LDAP gets configured to use RSA as a key >> > exchange algorithm, and fails, since the cert is an ECC cert. >> > >> > In /var/log/dirsrv/slapd-MYDOMAIN-COM/errors you can see: >> > [05/Nov/2015:12:22:36 +0000] - SSL alert: ConfigSecureServer: Server >> > key/certificate is bad for cert FreeIPA of family >> > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -12200 >> > - The certificate provided cannot be used with the selected key >> > exchange algorithm.) >> > >> > This is configured by ipaserver/install/dsinstance.py under def >> __enable_ssl: >> > >> > entry = conn.make_entry( >> > DN(('cn', 'RSA'), ('cn', 'encryption'), ('cn', 'config')), >> > objectclass=["top", "nsEncryptionModule"], >> > cn=["RSA"], >> > nsSSLPersonalitySSL=[self.nickname], >> > nsSSLToken=["internal (software)"], >> > nsSSLActivation=["on"], >> > ) >> > conn.add_entry(entry) >> > >> > My question is, is it possible to replace RSA with ECDSA here? If so, >> > what parameters should I pass to LDAP? >> >> Honza or Ludwig, do you know? This is certainly an uncharted territory, >> you are >> the first person I know about trying to install FreeIPA CA-less with ECC >> certificate. >> >> There is a ticket to get ECC support in PKI (i.e. not CA-less), but it was >> not >> completed yet: >> https://fedorahosted.org/freeipa/ticket/3951 >> >> > >> > If this is fixable, can someone add autodetect of the type of the >> > certificate and enable appropriate algorithms in LDAP and Apache? >> > >> > Best regards, >> > Marat Vyshegorodtsev >> > >> >> >-- >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 -- / Alexander Bokovoy From yamakasi.014 at gmail.com Fri Nov 6 12:28:41 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Nov 2015 13:28:41 +0100 Subject: [Freeipa-users] IPA Json Selfsigned certificate Message-ID: Hi guys, I'm testing out some installation and want to update my docs. I'm using a self signed cert and need to talk to the json/api. Which certs do I need to combine for my request, as I need an issuer too. The /etc/ipa/ca.crt combined with an export of the webcert ? Matt From pvoborni at redhat.com Fri Nov 6 14:28:08 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 6 Nov 2015 15:28:08 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: References: Message-ID: <563CB8F8.1080502@redhat.com> On 11/05/2015 05:32 PM, Andrew Holway wrote: > Actually I'm starting to feel like this is a bug. Managed to get the old > IPA server back up and ran . > > "ipa-server-install --uninstall" > > Which completed successfully and gave the advice: > > Replication agreements with the following IPA masters found: freeipa- > > prod-b-032.cloud.foo.com. Removing any replication agreements before > > uninstalling the server is strongly recommended. You can remove replication > > agreements by running the following command on any other IPA master: > > $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com > > > Running this command on the other IPA servers gives the following: > > > [root at freeipa-prod-a-033 centos]# ipa-replica-manage del > freeipa-prod-a-031.cloud.foo.com > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for' > freeipa-prod-a-031.cloud.foo.com' > > > I dont see anything in the logs. > > > Thanks, > > > Andrew > > On 5 November 2015 at 16:58, Andrew Holway wrote: > >> One of our FreeIPA replicas had its filesystem hosed so we want to remove >> it. Can someone show me the sequence of commands to remove a down replica? >> >> Thanks, >> >> Andrew >> >> >> >> [root at freeipa-prod-a-033 centos]# ipa-replica-manage list >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> freeipa-prod-a-031.cloud.foo.com: master >> >> freeipa-prod-a-033.cloud.foo.com: master >> >> freeipa-prod-b-032.cloud.foo.com: master >> >> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force >> freeipa-prod-a-031.foo.dcmn.com >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for' >> freeipa-prod-a-031.cloud.dcmn.com' >> If freeipa-prod-a-031 is already uninstall, use also --cleanup option: ipa-replica-manage del --force --cleanup freeipa-prod-a-031.foo.dcmn.com -f, --force Ignore some types of errors, don't prompt when deleting a master -c, --cleanup When deleting a master with the --force flag, remove leftover references to an already deleted master. -- Petr Vobornik From andrew.holway at gmail.com Fri Nov 6 14:37:45 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 6 Nov 2015 15:37:45 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: <563CB8F8.1080502@redhat.com> References: <563CB8F8.1080502@redhat.com> Message-ID: Thanks Petr, Tried this and get the following output with the verbose flag: p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes I still however see this machine as a nameserver for this domain. Also, SRV records pointing to it are still being served. [root at freeipa-prod-a-033 centos]# dig NS cloud.dcmn.com +short freeipa-prod-a-031.cloud.foo.com. freeipa-prod-b-032.cloud.foo.com. freeipa-prod-a-033.cloud.foo.com. Cheers, Andrew On 6 November 2015 at 15:28, Petr Vobornik wrote: > On 11/05/2015 05:32 PM, Andrew Holway wrote: > >> Actually I'm starting to feel like this is a bug. Managed to get the old >> IPA server back up and ran . >> >> "ipa-server-install --uninstall" >> >> Which completed successfully and gave the advice: >> >> Replication agreements with the following IPA masters found: freeipa- >> >> prod-b-032.cloud.foo.com. Removing any replication agreements before >> >> uninstalling the server is strongly recommended. You can remove >> replication >> >> agreements by running the following command on any other IPA master: >> >> $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com >> >> >> Running this command on the other IPA servers gives the following: >> >> >> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del >> freeipa-prod-a-031.cloud.foo.com >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for' >> freeipa-prod-a-031.cloud.foo.com' >> >> >> I dont see anything in the logs. >> >> >> Thanks, >> >> >> Andrew >> >> On 5 November 2015 at 16:58, Andrew Holway >> wrote: >> >> One of our FreeIPA replicas had its filesystem hosed so we want to remove >>> it. Can someone show me the sequence of commands to remove a down >>> replica? >>> >>> Thanks, >>> >>> Andrew >>> >>> >>> >>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage list >>> >>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >>> >>> freeipa-prod-a-031.cloud.foo.com: master >>> >>> freeipa-prod-a-033.cloud.foo.com: master >>> >>> freeipa-prod-b-032.cloud.foo.com: master >>> >>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force >>> freeipa-prod-a-031.foo.dcmn.com >>> >>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >>> >>> 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for' >>> freeipa-prod-a-031.cloud.dcmn.com' >>> >>> > If freeipa-prod-a-031 is already uninstall, use also --cleanup option: > > ipa-replica-manage del --force --cleanup freeipa-prod-a-031.foo.dcmn.com > > -f, --force > Ignore some types of errors, don't prompt when deleting a > master > -c, --cleanup > When deleting a master with the --force flag, remove > leftover references to an already deleted master. > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Nov 6 14:53:14 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 6 Nov 2015 15:53:14 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: References: <563CB8F8.1080502@redhat.com> Message-ID: <563CBEDA.5040002@redhat.com> On 11/06/2015 03:37 PM, Andrew Holway wrote: > Thanks Petr, > > Tried this and get the following output with the verbose flag: > > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > > Cleaning a master is irreversible. > > This should not normally be require, so use cautiously. > > Continue to clean master? [no]: yes > > > I still however see this machine as a nameserver for this domain. Also, SRV > records pointing to it are still being served. > > [root at freeipa-prod-a-033 centos]# dig NS cloud.dcmn.com +short > > freeipa-prod-a-031.cloud.foo.com. > > freeipa-prod-b-032.cloud.foo.com. > > freeipa-prod-a-033.cloud.foo.com. Then you can try to check DNS settings, easy in Web UI, and remove references to old server if there are any. > > > Cheers, > > Andrew > > > > On 6 November 2015 at 15:28, Petr Vobornik wrote: > >> On 11/05/2015 05:32 PM, Andrew Holway wrote: >> >>> Actually I'm starting to feel like this is a bug. Managed to get the old >>> IPA server back up and ran . >>> >>> "ipa-server-install --uninstall" >>> >>> Which completed successfully and gave the advice: >>> >>> Replication agreements with the following IPA masters found: freeipa- >>> >>> prod-b-032.cloud.foo.com. Removing any replication agreements before >>> >>> uninstalling the server is strongly recommended. You can remove >>> replication >>> >>> agreements by running the following command on any other IPA master: >>> >>> $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com >>> >>> >>> Running this command on the other IPA servers gives the following: >>> >>> >>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del >>> freeipa-prod-a-031.cloud.foo.com >>> >>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >>> >>> 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for' >>> freeipa-prod-a-031.cloud.foo.com' >>> >>> >>> I dont see anything in the logs. >>> >>> >>> Thanks, >>> >>> >>> Andrew >>> >>> On 5 November 2015 at 16:58, Andrew Holway >>> wrote: >>> >>> One of our FreeIPA replicas had its filesystem hosed so we want to remove >>>> it. Can someone show me the sequence of commands to remove a down >>>> replica? >>>> >>>> Thanks, >>>> >>>> Andrew >>>> >>>> >>>> >>>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage list >>>> >>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >>>> >>>> freeipa-prod-a-031.cloud.foo.com: master >>>> >>>> freeipa-prod-a-033.cloud.foo.com: master >>>> >>>> freeipa-prod-b-032.cloud.foo.com: master >>>> >>>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force >>>> freeipa-prod-a-031.foo.dcmn.com >>>> >>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >>>> >>>> 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for' >>>> freeipa-prod-a-031.cloud.dcmn.com' >>>> >>>> >> If freeipa-prod-a-031 is already uninstall, use also --cleanup option: >> >> ipa-replica-manage del --force --cleanup freeipa-prod-a-031.foo.dcmn.com >> >> -f, --force >> Ignore some types of errors, don't prompt when deleting a >> master >> -c, --cleanup >> When deleting a master with the --force flag, remove >> leftover references to an already deleted master. >> -- >> Petr Vobornik >> > -- Petr Vobornik From jcnt at use.startmail.com Fri Nov 6 16:08:57 2015 From: jcnt at use.startmail.com (jcnt at use.startmail.com) Date: Fri, 6 Nov 2015 11:08:57 -0500 Subject: [Freeipa-users] bringing up a new system into ipa domain Message-ID: Fresh install CentOS 7, selected graphical server, eventually booted into Create a Local Account screen, tried enterprise login with no results. Ctrl+Alt+F2 to to a shell, noticed that ipa-client is not installed (!), yum install ipa-client, manually joined IPA domain using ipa-client-install command (when will installer automatically stop and disable cronyd?), reboot, and stuck on the same Create a Local Account screen! Is there any way to overcome it without creating a local account? Regards, Josh. From cal-s at blue-bolt.com Fri Nov 6 16:16:05 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Fri, 6 Nov 2015 16:16:05 +0000 Subject: [Freeipa-users] IPA 4.1.0 UI certificate confusion Message-ID: <563CD245.7020905@blue-bolt.com> Hello I became aware the other day that building new IPA infrastructure on CentOS6 was seriously going to limit my ability to stay current with improvements, so i've rebuilt my primary and secondary IPA hosts on CentOS7 (one day apart). Installation went fine except that i cannot access one or the other host's UI (Error code: sec_error_reused_issuer_and_serial). This was never an issue in 3.0 where i could access either in the same browser session Using Firefox (38) and Chrome (46) I can access any one of the 2 hosts in any order on the first attempt (with Firefox only after deleting the previous host's cert) but the second host will always be inaccessible with ERR_SSL_SERVER_CERT_BAD_FORMAT. Chrome is similar, except it doesn't trust either host's certificate (red-crossed-out https in URL). I've confirmed this using a clean account as well. My working environment is CentOS 6.6. The Opera browser on the contrary sees both hosts equally well with zero complaints Is this behaviour by design or ? thanks -- Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadav.mavor at gmail.com Fri Nov 6 16:33:08 2015 From: nadav.mavor at gmail.com (Nadav Mavor) Date: Fri, 6 Nov 2015 11:33:08 -0500 Subject: [Freeipa-users] bringing up a new system into ipa domain In-Reply-To: References: Message-ID: you need to stop you firstimeboot scrip just rm -rf /etc/rc.d/init.d/firstboot On Fri, Nov 6, 2015 at 11:08 AM, wrote: > Fresh install CentOS 7, selected graphical server, > eventually booted into Create a Local Account screen, > tried enterprise login with no results. > Ctrl+Alt+F2 to to a shell, noticed that ipa-client is not installed (!), > yum install ipa-client, manually joined IPA domain using > ipa-client-install command > (when will installer automatically stop and disable cronyd?), > reboot, and stuck on the same Create a Local Account screen! > > Is there any way to overcome it without creating a local account? > > Regards, > Josh. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schogan at us.ibm.com Fri Nov 6 17:01:56 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Fri, 6 Nov 2015 10:01:56 -0700 Subject: [Freeipa-users] Can't contact LDAP Server In-Reply-To: <20151106083411.GO3242@hendrix> References: <201511060721.tA67LcEG009728@d01av01.pok.ibm.com><20151106081924.GN3242@hendrix> <20151106083411.GO3242@hendrix> Message-ID: <201511061702.tA6H29Ld010621@d01av02.pok.ibm.com> Hi Jakub, Negative.. only one domain. I just obscured the names here: Could not reconnect to domain.name provider. /var/log/dirsrv/slapd-DOMAIN-LOCAL Sean Hogan From: Jakub Hrozek To: freeipa-users at redhat.com Date: 11/06/2015 01:39 AM Subject: Re: [Freeipa-users] Can't contact LDAP Server Sent by: freeipa-users-bounces at redhat.com On Fri, Nov 06, 2015 at 09:19:24AM +0100, Jakub Hrozek wrote: > On Fri, Nov 06, 2015 at 12:21:29AM -0700, Sean Hogan wrote: > > > > > > Hi All, > > > > We are having an issue where a client is showing sssd eatting up 100% > > cpu and cannot log into it via ssh. IE.. trying to ssh to it just hangs an > > never prompts for password. We have to get to the box from the console at > > that point. > > > > Top output on client > > 2365 root -30 0 89600 79m 18m R 124.5 0.0 22:15.22 rmcd > > 2627 root 20 0 159m 27m 18m R 100.0 0.0 10:40.98 sssd_be > > 92718 root 20 0 159m 11m 2560 R 98.8 0.0 0:13.65 sssd_be > > Do you have one domain or two configured on the client? If only one, > then the two sssd_be processes would indicate sssd_be was restarted but > oops, restarted but the old one is still around. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 6 17:03:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 6 Nov 2015 18:03:11 +0100 Subject: [Freeipa-users] IPA 4.1.0 UI certificate confusion In-Reply-To: <563CD245.7020905@blue-bolt.com> References: <563CD245.7020905@blue-bolt.com> Message-ID: <563CDD4F.9050307@redhat.com> On 11/06/2015 05:16 PM, Cal Sawyer wrote: > Hello > > I became aware the other day that building new IPA infrastructure on CentOS6 > was seriously going to limit my ability to stay current with improvements, so > i've rebuilt my primary and secondary IPA hosts on CentOS7 (one day apart). > Installation went fine except that i cannot access one or the other host's UI > (Error code: sec_error_reused_issuer_and_serial). This was never an issue in > 3.0 where i could access either in the same browser session I rather think this is a problem of using the same browser against reinstalled FreeIPA, which have the same CA subject and same serial as the CentOS6 IPA, but different cert. Related thread: https://www.redhat.com/archives/freeipa-users/2015-September/msg00298.html Related ticket with workaround: https://fedorahosted.org/freeipa/ticket/2016 > Using Firefox (38) and Chrome (46) I can access any one of the 2 hosts in any > order on the first attempt (with Firefox only after deleting the previous > host's cert) but the second host will always be inaccessible with > ERR_SSL_SERVER_CERT_BAD_FORMAT. Chrome is similar, except it doesn't trust > either host's certificate (red-crossed-out https in URL). I've confirmed this > using a clean account as well. My working environment is CentOS 6.6. > > The Opera browser on the contrary sees both hosts equally well with zero complaints > > Is this behaviour by design or ? This is certainly not by design, I think it is all about the browser. Did you try the new CentOS7 with new browser or at least with a fresh Firefox profile, if it also gives you cert error? From andrew.holway at gmail.com Fri Nov 6 14:58:17 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 6 Nov 2015 15:58:17 +0100 Subject: [Freeipa-users] unable to delete dead freeipa replica In-Reply-To: <563CBEDA.5040002@redhat.com> References: <563CB8F8.1080502@redhat.com> <563CBEDA.5040002@redhat.com> Message-ID: Hi Petr, Ill do that thanks. This is pretty onerous work. There are quite a few resource records and each one has to be entered and cleaned. Easy to make mistakes. Do you have some idea why these records didn't get cleaned. If this happens in the future how should we handle it? We're using AWS so the chances of IPA servers falling over seems to be quite high :) Thanks Andrew On 6 November 2015 at 15:53, Petr Vobornik wrote: > On 11/06/2015 03:37 PM, Andrew Holway wrote: > >> Thanks Petr, >> >> Tried this and get the following output with the verbose flag: >> >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> >> Cleaning a master is irreversible. >> >> This should not normally be require, so use cautiously. >> >> Continue to clean master? [no]: yes >> >> >> I still however see this machine as a nameserver for this domain. Also, >> SRV >> records pointing to it are still being served. >> >> [root at freeipa-prod-a-033 centos]# dig NS cloud.dcmn.com +short >> >> freeipa-prod-a-031.cloud.foo.com. >> >> freeipa-prod-b-032.cloud.foo.com. >> >> freeipa-prod-a-033.cloud.foo.com. >> > > Then you can try to check DNS settings, easy in Web UI, and remove > references to old server if there are any. > > > >> >> Cheers, >> >> Andrew >> >> >> >> On 6 November 2015 at 15:28, Petr Vobornik wrote: >> >> On 11/05/2015 05:32 PM, Andrew Holway wrote: >>> >>> Actually I'm starting to feel like this is a bug. Managed to get the old >>>> IPA server back up and ran . >>>> >>>> "ipa-server-install --uninstall" >>>> >>>> Which completed successfully and gave the advice: >>>> >>>> Replication agreements with the following IPA masters found: freeipa- >>>> >>>> prod-b-032.cloud.foo.com. Removing any replication agreements before >>>> >>>> uninstalling the server is strongly recommended. You can remove >>>> replication >>>> >>>> agreements by running the following command on any other IPA master: >>>> >>>> $ ipa-replica-manage del freeipa-prod-a-031.cloud.foo.com >>>> >>>> >>>> Running this command on the other IPA servers gives the following: >>>> >>>> >>>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del >>>> freeipa-prod-a-031.cloud.foo.com >>>> >>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported >>>> attribute >>>> >>>> 'freeipa-prod-a-033.cloud.dcmn.com' has no replication agreement for' >>>> freeipa-prod-a-031.cloud.foo.com' >>>> >>>> >>>> I dont see anything in the logs. >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Andrew >>>> >>>> On 5 November 2015 at 16:58, Andrew Holway >>>> wrote: >>>> >>>> One of our FreeIPA replicas had its filesystem hosed so we want to >>>> remove >>>> >>>>> it. Can someone show me the sequence of commands to remove a down >>>>> replica? >>>>> >>>>> Thanks, >>>>> >>>>> Andrew >>>>> >>>>> >>>>> >>>>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage list >>>>> >>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported >>>>> attribute >>>>> >>>>> freeipa-prod-a-031.cloud.foo.com: master >>>>> >>>>> freeipa-prod-a-033.cloud.foo.com: master >>>>> >>>>> freeipa-prod-b-032.cloud.foo.com: master >>>>> >>>>> [root at freeipa-prod-a-033 centos]# ipa-replica-manage del --force >>>>> freeipa-prod-a-031.foo.dcmn.com >>>>> >>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported >>>>> attribute >>>>> >>>>> 'freeipa-prod-a-033.cloud.foo.com' has no replication agreement for' >>>>> freeipa-prod-a-031.cloud.dcmn.com' >>>>> >>>>> >>>>> If freeipa-prod-a-031 is already uninstall, use also --cleanup option: >>> >>> ipa-replica-manage del --force --cleanup freeipa-prod-a-031.foo.dcmn.com >>> >>> -f, --force >>> Ignore some types of errors, don't prompt when deleting a >>> master >>> -c, --cleanup >>> When deleting a master with the --force flag, remove >>> leftover references to an already deleted master. >>> -- >>> Petr Vobornik >>> >>> >> -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal-s at blue-bolt.com Fri Nov 6 17:28:41 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Fri, 6 Nov 2015 17:28:41 +0000 Subject: [Freeipa-users] IPA 4.1.0 UI certificate confusion In-Reply-To: <563CDD4F.9050307@redhat.com> References: <563CD245.7020905@blue-bolt.com> <563CDD4F.9050307@redhat.com> Message-ID: <563CE349.2050105@blue-bolt.com> Hi, Martin Many thanks for this info My user and personal workstations have to remain on CentOS6 until IPA is deployed across the board, when i think we might have better case for migrating to EL7. However, we also have loads of software with complex dependencies in production that makes major version updates precarious In answer to your question, yes, accessing these IPA servers from a fresh user account that's never seen these sites before exhibits the exact same issues whether in Firefox or Chrome - you ge the first one but the second (and 3rd, 4th - as many as you have) will block That idea of specifying a different timestamp in Subject when installing secondary instances seems worth trying right now and will report back cheers Cal Sawyer | Systems Engineer | BlueBolt Ltd On 06/11/15 17:03, Martin Kosek wrote: > On 11/06/2015 05:16 PM, Cal Sawyer wrote: >> Hello >> >> I became aware the other day that building new IPA infrastructure on >> CentOS6 >> was seriously going to limit my ability to stay current with >> improvements, so >> i've rebuilt my primary and secondary IPA hosts on CentOS7 (one day >> apart). >> Installation went fine except that i cannot access one or the other >> host's UI >> (Error code: sec_error_reused_issuer_and_serial). This was never an >> issue in >> 3.0 where i could access either in the same browser session > > I rather think this is a problem of using the same browser against > reinstalled FreeIPA, which have the same CA subject and same serial as > the CentOS6 IPA, but different cert. > > Related thread: > https://www.redhat.com/archives/freeipa-users/2015-September/msg00298.html > > > Related ticket with workaround: > https://fedorahosted.org/freeipa/ticket/2016 > >> Using Firefox (38) and Chrome (46) I can access any one of the 2 >> hosts in any >> order on the first attempt (with Firefox only after deleting the >> previous >> host's cert) but the second host will always be inaccessible with >> ERR_SSL_SERVER_CERT_BAD_FORMAT. Chrome is similar, except it doesn't >> trust >> either host's certificate (red-crossed-out https in URL). I've >> confirmed this >> using a clean account as well. My working environment is CentOS 6.6. >> >> The Opera browser on the contrary sees both hosts equally well with >> zero complaints >> >> Is this behaviour by design or ? > > This is certainly not by design, I think it is all about the browser. > Did you try the new CentOS7 with new browser or at least with a fresh > Firefox profile, if it also gives you cert error? From cal-s at blue-bolt.com Fri Nov 6 17:59:12 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Fri, 6 Nov 2015 17:59:12 +0000 Subject: [Freeipa-users] IPA 4.1.0 UI certificate confusion In-Reply-To: <563CE349.2050105@blue-bolt.com> References: <563CD245.7020905@blue-bolt.com> <563CDD4F.9050307@redhat.com> <563CE349.2050105@blue-bolt.com> Message-ID: <563CEA70.5020304@blue-bolt.com> Confirming that inclusion of a timestamped subject works well, Martin. Can open both instances in separate tabs the same Firefox session. Same is possible in Chrome, which dislikes the certs and does its red-cross thing many thanks for this fix! Cal Sawyer | Systems Engineer | BlueBolt Ltd On 06/11/15 17:28, Cal Sawyer wrote: > Hi, Martin > > Many thanks for this info > > My user and personal workstations have to remain on CentOS6 until IPA > is deployed across the board, when i think we might have better case > for migrating to EL7. However, we also have loads of software with > complex dependencies in production that makes major version updates > precarious > > In answer to your question, yes, accessing these IPA servers from a > fresh user account that's never seen these sites before exhibits the > exact same issues whether in Firefox or Chrome - you ge the first one > but the second (and 3rd, 4th - as many as you have) will block > > That idea of specifying a different timestamp in Subject when > installing secondary instances seems worth trying right now and will > report back > > cheers > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > > > On 06/11/15 17:03, Martin Kosek wrote: >> On 11/06/2015 05:16 PM, Cal Sawyer wrote: >>> Hello >>> >>> I became aware the other day that building new IPA infrastructure on >>> CentOS6 >>> was seriously going to limit my ability to stay current with >>> improvements, so >>> i've rebuilt my primary and secondary IPA hosts on CentOS7 (one day >>> apart). >>> Installation went fine except that i cannot access one or the other >>> host's UI >>> (Error code: sec_error_reused_issuer_and_serial). This was never an >>> issue in >>> 3.0 where i could access either in the same browser session >> >> I rather think this is a problem of using the same browser against >> reinstalled FreeIPA, which have the same CA subject and same serial >> as the CentOS6 IPA, but different cert. >> >> Related thread: >> https://www.redhat.com/archives/freeipa-users/2015-September/msg00298.html >> >> >> Related ticket with workaround: >> https://fedorahosted.org/freeipa/ticket/2016 >> >>> Using Firefox (38) and Chrome (46) I can access any one of the 2 >>> hosts in any >>> order on the first attempt (with Firefox only after deleting the >>> previous >>> host's cert) but the second host will always be inaccessible with >>> ERR_SSL_SERVER_CERT_BAD_FORMAT. Chrome is similar, except it doesn't >>> trust >>> either host's certificate (red-crossed-out https in URL). I've >>> confirmed this >>> using a clean account as well. My working environment is CentOS 6.6. >>> >>> The Opera browser on the contrary sees both hosts equally well with >>> zero complaints >>> >>> Is this behaviour by design or ? >> >> This is certainly not by design, I think it is all about the browser. >> Did you try the new CentOS7 with new browser or at least with a fresh >> Firefox profile, if it also gives you cert error? > From mkosek at redhat.com Fri Nov 6 18:45:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 6 Nov 2015 19:45:16 +0100 Subject: [Freeipa-users] IPA 4.1.0 UI certificate confusion In-Reply-To: <563CEA70.5020304@blue-bolt.com> References: <563CD245.7020905@blue-bolt.com> <563CDD4F.9050307@redhat.com> <563CE349.2050105@blue-bolt.com> <563CEA70.5020304@blue-bolt.com> Message-ID: <563CF53C.8000306@redhat.com> Good. But still, I am curious about your architecture. It almost looks like you are installing several FreeIPA servers (ipa-server-install), but with the same realm/domain. Can you share the reasoning? Maybe an advise can be given for the whole FreeIPA architecture. It is not something expected, normally you would install one FreeIPA server with realm "example.com" and then install replicas (ipa-replica-install) for redundancy or load balancing. On 11/06/2015 06:59 PM, Cal Sawyer wrote: > Confirming that inclusion of a timestamped subject works well, Martin. Can open > both instances in separate tabs the same Firefox session. Same is possible in > Chrome, which dislikes the certs and does its red-cross thing > > many thanks for this fix! > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > > > On 06/11/15 17:28, Cal Sawyer wrote: >> Hi, Martin >> >> Many thanks for this info >> >> My user and personal workstations have to remain on CentOS6 until IPA is >> deployed across the board, when i think we might have better case for >> migrating to EL7. However, we also have loads of software with complex >> dependencies in production that makes major version updates precarious >> >> In answer to your question, yes, accessing these IPA servers from a fresh >> user account that's never seen these sites before exhibits the exact same >> issues whether in Firefox or Chrome - you ge the first one but the second >> (and 3rd, 4th - as many as you have) will block >> >> That idea of specifying a different timestamp in Subject when installing >> secondary instances seems worth trying right now and will report back >> >> cheers >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> >> >> On 06/11/15 17:03, Martin Kosek wrote: >>> On 11/06/2015 05:16 PM, Cal Sawyer wrote: >>>> Hello >>>> >>>> I became aware the other day that building new IPA infrastructure on CentOS6 >>>> was seriously going to limit my ability to stay current with improvements, so >>>> i've rebuilt my primary and secondary IPA hosts on CentOS7 (one day apart). >>>> Installation went fine except that i cannot access one or the other host's UI >>>> (Error code: sec_error_reused_issuer_and_serial). This was never an issue in >>>> 3.0 where i could access either in the same browser session >>> >>> I rather think this is a problem of using the same browser against >>> reinstalled FreeIPA, which have the same CA subject and same serial as the >>> CentOS6 IPA, but different cert. >>> >>> Related thread: >>> https://www.redhat.com/archives/freeipa-users/2015-September/msg00298.html >>> >>> Related ticket with workaround: >>> https://fedorahosted.org/freeipa/ticket/2016 >>> >>>> Using Firefox (38) and Chrome (46) I can access any one of the 2 hosts in any >>>> order on the first attempt (with Firefox only after deleting the previous >>>> host's cert) but the second host will always be inaccessible with >>>> ERR_SSL_SERVER_CERT_BAD_FORMAT. Chrome is similar, except it doesn't trust >>>> either host's certificate (red-crossed-out https in URL). I've confirmed this >>>> using a clean account as well. My working environment is CentOS 6.6. >>>> >>>> The Opera browser on the contrary sees both hosts equally well with zero >>>> complaints >>>> >>>> Is this behaviour by design or ? >>> >>> This is certainly not by design, I think it is all about the browser. Did >>> you try the new CentOS7 with new browser or at least with a fresh Firefox >>> profile, if it also gives you cert error? >> > From prasun.gera at gmail.com Sun Nov 8 05:15:52 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sat, 7 Nov 2015 21:15:52 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> Message-ID: Thanks for the discussion. If someone can update the documentation with mozilla style old, intermediate and modern cipher lists for mod_nss, that would be great. Better still would be to add that option to the installer scripts so that you can choose it during installation. Integrating that in the package would also have the added benefit of settings remaining up to date without manual intervention as standards evolve. On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale wrote: > On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > > Prasun Gera wrote: > > > Thanks. After the changes, most things seem to be in order. I see two > > > orange flags though: > > > > > > Secure Client-Initiated Renegotiation *Supported* *DoS DANGER* > (more > > > info > > > < > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > >) > > > > Renegotiation is required for the CA so you need to leave this enabled. > > > > > Session resumption (caching) *No (IDs assigned but not > accepted)* > > > > I'll need to look at this in more detail. At worst it would slow new > > connection performance slightly as it means every connection requires a > > full SSL/TLS handshake. I don't think it's a show-stopper. > > > Definitely not a show-stopper. The main reason this is an "orange" > alert in SSLLabs is because the server is assigning Session IDs but > then ignoring them; although confusing it is a fairly common default > behaviour and doesn't cause any issues with compliant client > implementation > > > rob > > > > > > > > Are these relevant/serious ? Can they be mitigated ? > > > > > > > > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden > > > wrote: > > > > > > Prasun Gera wrote: > > > > Yes, that's what I was planning to do. i.e. Convert cipher names > from > > > > SSL to NSS. I wasn't sure about the other settings though. Is > there an > > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, > are there > > > > equivalent configs for HSTS on the mozilla page? Does NSS allow > using > > > > generated DH parameters instead of standard ones ? For SSL, the > > > > suggested modification to the config is 'SSLOpenSSLConfCmd > DHParameters > > > > "{path to dhparams.pem}"' after generating the params. > > > > > > NSS does not let the user specify cipher order. It uses its own > internal > > > sorting from strongest to weakest. > > > > > > HSTS is a header and not dependent upon SSL provider. > > > > > > mod_nss doesn't support DH ciphers. > > > > > > rob > > > > > > > > > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > ftweedal at redhat.com > > > > >> > wrote: > > > > > > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > > > > > Thanks for the ticket information. I would still be > interested in > > > > > configuring mod_nss properly (irrespective of whether the > certs are ipa > > > > > generated or 3rd party). These are the worrying notes from > ssllabs test: > > > > > > > > > > The server supports only older protocols, but not the > current best TLS 1.2. > > > > > Grade capped to C. > > > > > This server accepts the RC4 cipher, which is weak. Grade > capped to B. > > > > > The server does not support Forward Secrecy with the > reference browsers. > > > > > > > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > > > > starting point. See also the "Cipher names correspondence > table" on > > > > the same page for translating it to cipher names understood > by NSS > > > > to construct a valid setting for the `NSSCipherSuite' > directive. > > > > > > > > [1] > > > > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > > > > > > Cheers, > > > > Fraser > > > > > > > > > > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > > > > > >> wrote: > > > > > > > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera > wrote: > > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > > > accessible > > > > publicly. > > > > > > I'm > > > > > > > using a stock configuration which uses the certs > signed by > > > > ipa's CA for > > > > > > the > > > > > > > webui. This is mostly for convenience since it manages > > > renewals > > > > > > seamlessly. > > > > > > > This, however, requires users to add the CA as trusted > > > to their > > > > > > browsers. A > > > > > > > promising alternative to this is > https://letsencrypt.org/, > > > > which issues > > > > > > > browser trusted certs, and will manage auto renewals > too (in > > > > the future). > > > > > > > As a feature request, it would be nice to have closer > > > > integration between > > > > > > > ipa and the letsencrypt client which would make > managing > > > certs > > > > simple. > > > > > > I'm > > > > > > > about to set this up manually right now using the > > > external ssl > > > > certs > > > > > > guide. > > > > > > > > > > > > > Let's Encrypt is on our radar. I like the idea of being > > > able to > > > > > > install FreeIPA with publicly-trusted certs for HTTP and > > > LDAP from > > > > > > the beginning. This would require some work in > > > ipa-server-install > > > > > > in addition to certmonger support and a good, stable > Let's > > > Encrypt / > > > > > > ACME client implementation for Apache on Fedora. > > > > > > > > > > > > Installing publicly-trusted HTTP / LDAP certs is a common > > > activity > > > > > > so I filed a ticket: > > > https://fedorahosted.org/freeipa/ticket/5431 > > > > > > > > > > > > Cheers, > > > > > > Fraser > > > > > > > > > > > > > Secondly, since the webui uses mod_nss, how would one > set it > > > > up to prefer > > > > > > > security over compatibility with older clients ? The > vast > > > > majority of > > > > > > > documentation online (for eg. > > > > > > > > > > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > is > > > > > > about > > > > > > > mod_ssl and I think the configuration doesn't transfer > > > directly to > > > > > > mod_nss. > > > > > > > Since this is the only web facing component, I would > like to > > > > set it up to > > > > > > > use stringent requirements. Right now, a test on > > > > > > > https://www.ssllabs.com/ssltest/ and > > > > https://weakdh.org/sysadmin.html > > > > > > > identifies > > > > > > > several issues. Since these things are not really my > area of > > > > expertise, I > > > > > > > would like some documentation regarding this. Also, > > > would manually > > > > > > > modifying any of the config files be overwritten by a > > > yum update ? > > > > > > > > > > > > > -- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Sun Nov 8 13:07:23 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sun, 8 Nov 2015 14:07:23 +0100 Subject: [Freeipa-users] SSO Git http smart server and freeipa group authentication Message-ID: Hello, Anyone got git-http-backend working with freeipa group auhentication and would like to share their apache .conf file? I've tried this on the IPA server with a dummy git repository setup in /opt/gitrepos/test1.git gitserver.my.lan is a CNAME for ipaserver.my.lan First, "git clone http://gitserver.my.lan/test1.git" prompts (even though I have a ticket) for user+pwd but still fails. Any suggestions are welcome! -- john DocumentRoot /opt/gitrepos # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?' # restorecon -R -v /opt/gitrepos SetEnv GIT_PROJECT_ROOT /opt/gitrepos SetEnv GIT_HTTP_EXPORT_ALL SetEnv REMOTE_USER $REDIRECT_REMOTE_USER ScriptAlias / /usr/libexec/git-core/git-http-backend/ ServerName gitserver.my.lan Options Indexes AllowOverride None Require all granted Options Indexes AllowOverride None Require all granted AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm MY.LAN Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbMethodNegotiate on KrbMethodK5Passwd off KrbSaveCredentials on KrbVerifyKDC on KrbServiceName HTTP AuthLDAPUrl ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName Require ldap-group cn=ipausers,dc=my,dc=lan # Allow anyone authenticated users that are ina ipausers group to clone ~ ~ ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcnt at use.startmail.com Sun Nov 8 16:02:42 2015 From: jcnt at use.startmail.com (jcnt at use.startmail.com) Date: Sun, 8 Nov 2015 11:02:42 -0500 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: <20151106082453.GV8374@redhat.com> References: <563BA5D2.5020904@redhat.com> <20151106082453.GV8374@redhat.com> Message-ID: <18bc005bf269200fca60509502105a54.startmail@www.startmail.com> On Friday, November 6, 2015 3:24 AM, Alexander Bokovoy wrote: > On Thu, 05 Nov 2015, jcnt at use.startmail.com wrote: >>On Thursday, November 5, 2015 1:54 PM, Rob Crittenden >> wrote: >>> jcnt at use.startmail.com wrote: >>>> Hello everyone, [...] > > Your workflow should be something like this (using IPA CLI as an example > here): > 1. Create a service with 'ipa service-add' > 2. Associate a key with a service with 'ipa-getkeytab' and store it in a > keytab -- either directly on the server where service is running or on > any other IPA client. > 3. Deliver the keytab from step (2) to a server where it should be if > needed. In case of clustered configuration deliver the keytab to all > cluster nodes which will be operating as the service. > > Do not run 'ipa-getkeytab' multiple times as each run invalidates > previously obtained keytab. > > 4. Use the keytab to kinit and obtain initial ticket granting ticket > (TGT) for the service principal periodically. This either has to be > supported by an application itself or run with a wrapper that kinits > periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to > perform automatic renewal, this is much cleaner way of doing it. > > If your NAS appliance has issues like below it only says that NFS server > side did not accept your configuration. Thus, you need to look into the > NAS appliance logs to say what is wrong there. To eliminate NAS appliance I am following section 16.3.1 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kerb-nfs.html#krb-nfs-server literally on a fresh CentOS 7 lab network consisting of one IPA server, one IPA client and a stand alone NFS server. For IPA server I created nfs service using ipa service-add nfs/fds.example.org followed by ipa-getkeytab -s fds.example.org -p nfs/fds.example.org -k /tmp/nfsserverfds.keytab then used ktutil to merge into host keytab. klist -k confirms that host and nfs principals are present. created /etc/exports like /home *(rw,insecure,sec=krb5) and enabled nfs-server service (I also disabled NFSv3) krb5 mount between IPA client and IPA server works without any problems. # mount -vvv -o sec=krb5 fds:/home /mnt mount.nfs: timeout set for Sun Nov 8 10:59:53 2015 mount.nfs: trying text-based options 'sec=krb5,vers=4,addr=192.168.1.3,clientaddr=192.168.1.131' However, when I repeat exactly the same service-add and getkeytab steps for a stand alone NFS server, mount is denied. kinit -k nfs/nfsserver.example.org works (I added default realm in /etc/krb5.conf) Starting gssproxy in debug mode like /usr/sbin/gssproxy -di shows following during mount attempt: Debug Enabled Client connected (fd = 11) (pid = 2157) (uid = 0) (gid = 0) (context = system_u:system_r:kernel_t:s0) gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock /usr/sbin/rpc.gssd -vvv -f shows only beginning poll Does anyone know how to enable more verbosity from NFS components to find out what is missing in stand alone server configuration? Regards, Josh. From simo at redhat.com Sun Nov 8 22:55:19 2015 From: simo at redhat.com (Simo Sorce) Date: Sun, 8 Nov 2015 17:55:19 -0500 Subject: [Freeipa-users] SSO Git http smart server and freeipa group authentication In-Reply-To: References: Message-ID: <563FD2D7.8040102@redhat.com> On 08/11/15 08:07, John Obaterspok wrote: > Hello, > > Anyone got git-http-backend working with freeipa group auhentication and > would like to share their apache .conf file? > > > I've tried this on the IPA server with a dummy git repository setup in > /opt/gitrepos/test1.git > gitserver.my.lan is a CNAME for ipaserver.my.lan > > First, "git clone http://gitserver.my.lan/test1.git" prompts (even though I > have a ticket) for user+pwd but still fails. > > Any suggestions are welcome! > > -- john > > > > > DocumentRoot /opt/gitrepos > > # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?' > # restorecon -R -v /opt/gitrepos > > SetEnv GIT_PROJECT_ROOT /opt/gitrepos > SetEnv GIT_HTTP_EXPORT_ALL > SetEnv REMOTE_USER $REDIRECT_REMOTE_USER > ScriptAlias / /usr/libexec/git-core/git-http-backend/ > ServerName gitserver.my.lan > > > Options Indexes > AllowOverride None > Require all granted > > > > Options Indexes > AllowOverride None > Require all granted > > > > AuthType Kerberos > AuthName "Kerberos Login" > KrbAuthRealm MY.LAN > Krb5KeyTab /etc/httpd/conf/ipa.keytab > KrbMethodNegotiate on > KrbMethodK5Passwd off > KrbSaveCredentials on > KrbVerifyKDC on > KrbServiceName HTTP > > AuthLDAPUrl > ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName > Require ldap-group cn=ipausers,dc=my,dc=lan This should probably be somehting like: cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan Although you should probably create a git specific group, especially if you want it to be a posix group that can own files (ipausers is not a posix group and we are actually trying to phase it out) Also you are not doing LDAP authentication, you only want to do authorization, and for that you may want to actually use nsswitch based authorization which can be cached by sssd and not a query out to LDAP for each connection. Unfortunately the basic Apache modules do not support system group authentication directly, so what you may do instead is to have a cron job that do the following: getent group git-users | cut -d: -f1,4 |tr ',' ' ' > /my/authorization/file And in apache have set the following directives instead of the above two: AuthGroupFile /my/authorization/file Require group git-users HTH, Simo -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Sun Nov 8 22:59:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 9 Nov 2015 08:59:54 +1000 Subject: [Freeipa-users] SSO Git http smart server and freeipa group authentication In-Reply-To: References: Message-ID: <20151108225954.GC31495@dhcp-40-8.bne.redhat.com> On Sun, Nov 08, 2015 at 02:07:23PM +0100, John Obaterspok wrote: > Hello, > > Anyone got git-http-backend working with freeipa group auhentication and > would like to share their apache .conf file? > > > I've tried this on the IPA server with a dummy git repository setup in > /opt/gitrepos/test1.git > gitserver.my.lan is a CNAME for ipaserver.my.lan > > First, "git clone http://gitserver.my.lan/test1.git" prompts (even though I > have a ticket) for user+pwd but still fails. > > Any suggestions are welcome! > > -- john > > > > > DocumentRoot /opt/gitrepos > > # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?' > # restorecon -R -v /opt/gitrepos > > SetEnv GIT_PROJECT_ROOT /opt/gitrepos > SetEnv GIT_HTTP_EXPORT_ALL > SetEnv REMOTE_USER $REDIRECT_REMOTE_USER > ScriptAlias / /usr/libexec/git-core/git-http-backend/ > ServerName gitserver.my.lan > > > Options Indexes > AllowOverride None > Require all granted > > > > Options Indexes > AllowOverride None > Require all granted > > > > AuthType Kerberos > AuthName "Kerberos Login" > KrbAuthRealm MY.LAN > Krb5KeyTab /etc/httpd/conf/ipa.keytab > KrbMethodNegotiate on > KrbMethodK5Passwd off > KrbSaveCredentials on > KrbVerifyKDC on > KrbServiceName HTTP > > AuthLDAPUrl > ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName > Require ldap-group cn=ipausers,dc=my,dc=lan > # Allow anyone authenticated users that are ina ipausers > group to clone > > > ~ > ~ > ~ Hi John, Have a look at this Stack Overflow question: http://stackoverflow.com/questions/32788405/how-to-force-git-2-5-http-transport-prefer-spnego-over-basic-authentication Make sure you provide a (fake) username to trigger the SPNEGO authentication code. If this does not work please run with `GIT_CURL_VERBOSE=1' in environment to reveal what is going on behind the scenes. Cheers, Fraser > -- > 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 From ftweedal at redhat.com Sun Nov 8 23:04:46 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 9 Nov 2015 09:04:46 +1000 Subject: [Freeipa-users] IPA Json Selfsigned certificate In-Reply-To: References: Message-ID: <20151108230446.GD31495@dhcp-40-8.bne.redhat.com> On Fri, Nov 06, 2015 at 01:28:41PM +0100, Matt . wrote: > Hi guys, > > I'm testing out some installation and want to update my docs. > > I'm using a self signed cert and need to talk to the json/api. > > Which certs do I need to combine for my request, as I need an issuer too. > > The /etc/ipa/ca.crt combined with an export of the webcert ? > > Matt > Is the HTTP certificate signed by /etc/ipa/ca.crt? If so, you only need to make sure that /etc/ipa/ca.crt is a trusted root. Cheers, Fraser > -- > 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 From yamakasi.014 at gmail.com Sun Nov 8 23:32:57 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 9 Nov 2015 00:32:57 +0100 Subject: [Freeipa-users] IPA Json Selfsigned certificate In-Reply-To: <20151108230446.GD31495@dhcp-40-8.bne.redhat.com> References: <20151108230446.GD31495@dhcp-40-8.bne.redhat.com> Message-ID: Hi, Yes I found that out using some blof of Alexander. Thanks! as I thought we needed a combination of the issues also, but I saw one some tetsmachine this was not needed anymore, cannot say about the past anymore. Cheers, Matt 2015-11-09 0:04 GMT+01:00 Fraser Tweedale : > On Fri, Nov 06, 2015 at 01:28:41PM +0100, Matt . wrote: >> Hi guys, >> >> I'm testing out some installation and want to update my docs. >> >> I'm using a self signed cert and need to talk to the json/api. >> >> Which certs do I need to combine for my request, as I need an issuer too. >> >> The /etc/ipa/ca.crt combined with an export of the webcert ? >> >> Matt >> > Is the HTTP certificate signed by /etc/ipa/ca.crt? If so, you only > need to make sure that /etc/ipa/ca.crt is a trusted root. > > Cheers, > Fraser > >> -- >> 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 From pspacek at redhat.com Mon Nov 9 07:53:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 Nov 2015 08:53:34 +0100 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: <18bc005bf269200fca60509502105a54.startmail@www.startmail.com> References: <563BA5D2.5020904@redhat.com> <20151106082453.GV8374@redhat.com> <18bc005bf269200fca60509502105a54.startmail@www.startmail.com> Message-ID: <564050FE.209@redhat.com> On 8.11.2015 17:02, jcnt at use.startmail.com wrote: > On Friday, November 6, 2015 3:24 AM, Alexander Bokovoy wrote: >> On Thu, 05 Nov 2015, jcnt at use.startmail.com wrote: >>> On Thursday, November 5, 2015 1:54 PM, Rob Crittenden >>> wrote: >>>> jcnt at use.startmail.com wrote: >>>>> Hello everyone, > [...] >> >> Your workflow should be something like this (using IPA CLI as an example >> here): >> 1. Create a service with 'ipa service-add' >> 2. Associate a key with a service with 'ipa-getkeytab' and store it in a >> keytab -- either directly on the server where service is running or on >> any other IPA client. >> 3. Deliver the keytab from step (2) to a server where it should be if >> needed. In case of clustered configuration deliver the keytab to all >> cluster nodes which will be operating as the service. >> >> Do not run 'ipa-getkeytab' multiple times as each run invalidates >> previously obtained keytab. >> >> 4. Use the keytab to kinit and obtain initial ticket granting ticket >> (TGT) for the service principal periodically. This either has to be >> supported by an application itself or run with a wrapper that kinits >> periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to >> perform automatic renewal, this is much cleaner way of doing it. >> >> If your NAS appliance has issues like below it only says that NFS server >> side did not accept your configuration. Thus, you need to look into the >> NAS appliance logs to say what is wrong there. > > To eliminate NAS appliance I am following section 16.3.1 > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kerb-nfs.html#krb-nfs-server > literally on a fresh CentOS 7 lab network consisting of one IPA server, one IPA client and a stand alone NFS server. > For IPA server I created nfs service using > ipa service-add nfs/fds.example.org > followed by > ipa-getkeytab -s fds.example.org -p nfs/fds.example.org -k /tmp/nfsserverfds.keytab > then used ktutil to merge into host keytab. > klist -k confirms that host and nfs principals are present. > created /etc/exports like /home *(rw,insecure,sec=krb5) and enabled nfs-server service > (I also disabled NFSv3) > krb5 mount between IPA client and IPA server works without any problems. > > # mount -vvv -o sec=krb5 fds:/home /mnt > mount.nfs: timeout set for Sun Nov 8 10:59:53 2015 > mount.nfs: trying text-based options 'sec=krb5,vers=4,addr=192.168.1.3,clientaddr=192.168.1.131' > > However, when I repeat exactly the same service-add and getkeytab steps for a stand alone NFS server, mount is denied. What do you mean, exactly, by 'stand alone NFS server'? Is it another server which did not executed ipa-client-install? Or something else? Petr^2 Spacek > > kinit -k nfs/nfsserver.example.org > works (I added default realm in /etc/krb5.conf) > > Starting gssproxy in debug mode like > /usr/sbin/gssproxy -di shows following during mount attempt: > > Debug Enabled > Client connected (fd = 11) (pid = 2157) (uid = 0) (gid = 0) (context = system_u:system_r:kernel_t:s0) > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock > > /usr/sbin/rpc.gssd -vvv -f > shows only > beginning poll > > Does anyone know how to enable more verbosity from NFS components to find out what is missing in stand alone server configuration? > > Regards, > Josh. > -- Petr^2 Spacek From Christopher.Gronde at fincen.gov Mon Nov 9 15:39:35 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Mon, 9 Nov 2015 15:39:35 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Message-ID: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> Hello all! On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. # service krb5kdc start Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] # cat /var/log/krb5kdc.log krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV I found this article online: http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml Which stated it might be because The slave KDC does not have a stash file (.k5.EXAMPLE.COM). You need to create one. Tried the command listed: # kdb5_util stash kdb5_util: Server error while retrieving master entry No further information found on the proceeding error above for the kdb5_util command. Any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Nov 9 15:50:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Nov 2015 17:50:52 +0200 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> Message-ID: <20151109155052.GC1147@redhat.com> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >Hello all! > >On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. > ># service krb5kdc start >Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] > ># cat /var/log/krb5kdc.log >krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV >krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV >krb5kdc: Server error - while fetching master key K/M for realm ITMODEV.GOV > >I found this article online: http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml > >Which stated it might be because The slave KDC does not have a stash >file (.k5.EXAMPLE.COM). You need to create one. Tried the command >listed: > ># kdb5_util stash >kdb5_util: Server error while retrieving master entry > >No further information found on the proceeding error above for the kdb5_util command. > >Any thoughts? First: don't use instructions which are not related to IPA, please. FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? -- / Alexander Bokovoy From Christopher.Gronde at fincen.gov Mon Nov 9 16:16:10 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Mon, 9 Nov 2015 16:16:10 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <20151109155052.GC1147@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> I restarted dirsrv and attempted to start krb5kdc and this is what the error log shows # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling operation threads [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down internal subsystems and plugins [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop [09/Nov/2015:11:06:04 -0500] - All database threads now stopped [09/Nov/2015:11:06:04 -0500] - slapd stopped. [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 starting up [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Monday, November 09, 2015 10:51 AM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >Hello all! > >On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. > ># service krb5kdc start >Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] > ># cat /var/log/krb5kdc.log >krb5kdc: Server error - while fetching master key K/M for realm >ITMODEV.GOV >krb5kdc: Server error - while fetching master key K/M for realm >ITMODEV.GOV >krb5kdc: Server error - while fetching master key K/M for realm >ITMODEV.GOV > >I found this article online: >http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml > >Which stated it might be because The slave KDC does not have a stash >file (.k5.EXAMPLE.COM). You need to create one. Tried the command >listed: > ># kdb5_util stash >kdb5_util: Server error while retrieving master entry > >No further information found on the proceeding error above for the kdb5_util command. > >Any thoughts? First: don't use instructions which are not related to IPA, please. FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? -- / Alexander Bokovoy From rcritten at redhat.com Mon Nov 9 16:45:41 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Nov 2015 11:45:41 -0500 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> Message-ID: <5640CDB5.4000707@redhat.com> Gronde, Christopher (Contractor) wrote: > I restarted dirsrv and attempted to start krb5kdc and this is what the error log shows > > # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors > [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. > [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling operation threads > [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down internal subsystems and plugins > [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop > [09/Nov/2015:11:06:04 -0500] - All database threads now stopped > [09/Nov/2015:11:06:04 -0500] - slapd stopped. > [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 starting up > [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. > [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests Ok, that's good. I'd do something like this to see what is in the db (substitute example.com with your domain): $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b cn=kerberos,dc=example,dc=com (don't post the output as it would include the kerberos master key). If that returns nothing that's bad. If it succeeds I'd broaden the search base a bit to see what data you do have: $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=groups,cn=accounts,dc=example,dc=com I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. Let us know if either or both turns up nothing. rob > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Monday, November 09, 2015 10:51 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >> Hello all! >> >> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >> >> # service krb5kdc start >> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >> >> # cat /var/log/krb5kdc.log >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> >> I found this article online: >> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >> >> Which stated it might be because The slave KDC does not have a stash >> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >> listed: >> >> # kdb5_util stash >> kdb5_util: Server error while retrieving master entry >> >> No further information found on the proceeding error above for the kdb5_util command. >> >> Any thoughts? > First: don't use instructions which are not related to IPA, please. > > FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. > > If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? > > -- > / Alexander Bokovoy > > From oliver at doerr-privat.de Mon Nov 9 17:58:56 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Mon, 9 Nov 2015 18:58:56 +0100 Subject: [Freeipa-users] First tests against the REST/JSON API Message-ID: <5640DEE0.20107@doerr-privat.de> Hi, I'm completly new to this list and the product behind it. I'm trying to use perl to get a list from my IPA installation of all users that are on the server. #!/usr/bin/perl use strict; use REST::Client; use JSON; use Data::Dumper; use MIME::Base64; my $username="admin"; my $password="secret"; my $headers= { 'Accept' => 'application/json', 'Content-Type' => 'application/x-www-form-urlencoded', 'Authorization' => 'Basic', 'user' => encode_base64($username), 'password' => encode_base64($password) #encode_base64($username.":".$password) }; my $client=REST::Client->new(); $client->setHost("https://ipa.kreditwerk.de"); $client->POST("/ipa/session/login_password", $headers); print Dumper $client->responseContent(); Sadly I get back $VAR1 = '500 Not a SCALAR reference '; I can't find any hinside the error log of the apache, even with debug enabled. I can't find any thing in the internet that helps me. (Perhaps I do not know where to look for). So any idea where I should look at it to troubleshoot this problem? Thanks oliver From lists at fahrendorf.de Mon Nov 9 18:38:56 2015 From: lists at fahrendorf.de (Martin (Lists)) Date: Mon, 9 Nov 2015 19:38:56 +0100 Subject: [Freeipa-users] adding user to a group failed Message-ID: <5640E840.2050809@fahrendorf.de> Hallo recently I tried to add a user to one of my groups, but this always failed with the error message: This entry already exists. Of course does this entry (user) exists, but not in this group. and it is not added. I tried to add this from web interface and command line with the same result. I use freeipa version 4.1.4 on fedora 22 Anyone with a tip? Regards Martin From Christopher.Gronde at fincen.gov Mon Nov 9 18:56:24 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Mon, 9 Nov 2015 18:56:24 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <5640CDB5.4000707@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> Nothing bad came back and there is definitely data in the tree. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, November 09, 2015 11:46 AM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > I restarted dirsrv and attempted to start krb5kdc and this is what the > error log shows > > # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors > [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. > [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling > operation threads > [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop > [09/Nov/2015:11:06:04 -0500] - All database threads now stopped > [09/Nov/2015:11:06:04 -0500] - slapd stopped. > [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 > starting up > [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. > [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests Ok, that's good. I'd do something like this to see what is in the db (substitute example.com with your domain): $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b cn=kerberos,dc=example,dc=com (don't post the output as it would include the kerberos master key). If that returns nothing that's bad. If it succeeds I'd broaden the search base a bit to see what data you do have: $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=groups,cn=accounts,dc=example,dc=com I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. Let us know if either or both turns up nothing. rob > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Monday, November 09, 2015 10:51 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >> Hello all! >> >> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >> >> # service krb5kdc start >> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >> >> # cat /var/log/krb5kdc.log >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> krb5kdc: Server error - while fetching master key K/M for realm >> ITMODEV.GOV >> >> I found this article online: >> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >> >> Which stated it might be because The slave KDC does not have a stash >> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >> listed: >> >> # kdb5_util stash >> kdb5_util: Server error while retrieving master entry >> >> No further information found on the proceeding error above for the kdb5_util command. >> >> Any thoughts? > First: don't use instructions which are not related to IPA, please. > > FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. > > If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? > > -- > / Alexander Bokovoy > > From lists at fahrendorf.de Mon Nov 9 19:05:50 2015 From: lists at fahrendorf.de (Martin (Lists)) Date: Mon, 9 Nov 2015 20:05:50 +0100 Subject: [Freeipa-users] adding user to a group failed In-Reply-To: <5640E840.2050809@fahrendorf.de> References: <5640E840.2050809@fahrendorf.de> Message-ID: <5640EE8E.1020204@fahrendorf.de> Am 09.11.2015 um 19:38 schrieb Martin (Lists): > Hallo > > recently I tried to add a user to one of my groups, but this always > failed with the error message: This entry already exists. > > Of course does this entry (user) exists, but not in this group. and it > is not added. I tried to add this from web interface and command line > with the same result. > > I use freeipa version 4.1.4 on fedora 22 > > Anyone with a tip? > > Regards > Martin > Sorry for the noise, found it. I had a failing index (from yesterday reindex) and this prohibited every change to my ldap server. Regards Martin From rcritten at redhat.com Mon Nov 9 20:25:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Nov 2015 15:25:57 -0500 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> Message-ID: <56410155.2090009@redhat.com> Gronde, Christopher (Contractor) wrote: > Nothing bad came back and there is definitely data in the tree. Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: 1. See if it is binding at all 2. See what the search is and what, if any, results were returned This would be in /var/log/dirsrv/slapd-YOUR_REALM/access rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, November 09, 2015 11:46 AM > To: Gronde, Christopher (Contractor) ; Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > Gronde, Christopher (Contractor) wrote: >> I restarted dirsrv and attempted to start krb5kdc and this is what the >> error log shows >> >> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >> operation threads >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop >> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 >> starting up >> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests > > Ok, that's good. > > I'd do something like this to see what is in the db (substitute example.com with your domain): > > $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b cn=kerberos,dc=example,dc=com > > (don't post the output as it would include the kerberos master key). > > If that returns nothing that's bad. > > If it succeeds I'd broaden the search base a bit to see what data you do > have: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=groups,cn=accounts,dc=example,dc=com > > I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. > > Let us know if either or both turns up nothing. > > rob > >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Monday, November 09, 2015 10:51 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> Hello all! >>> >>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>> >>> # service krb5kdc start >>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>> >>> # cat /var/log/krb5kdc.log >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> >>> I found this article online: >>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>> >>> Which stated it might be because The slave KDC does not have a stash >>> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >>> listed: >>> >>> # kdb5_util stash >>> kdb5_util: Server error while retrieving master entry >>> >>> No further information found on the proceeding error above for the kdb5_util command. >>> >>> Any thoughts? >> First: don't use instructions which are not related to IPA, please. >> >> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >> >> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >> >> -- >> / Alexander Bokovoy >> >> > > From Christopher.Gronde at fincen.gov Mon Nov 9 20:35:04 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Mon, 9 Nov 2015 20:35:04 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56410155.2090009@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828B8CA@hqexdb01.hqfincen.gov> When I tried to start the service again I got no response from tail of the log, but this is a repeating entry I see in the access log [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from to [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, November 09, 2015 3:26 PM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > Nothing bad came back and there is definitely data in the tree. Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: 1. See if it is binding at all 2. See what the search is and what, if any, results were returned This would be in /var/log/dirsrv/slapd-YOUR_REALM/access rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, November 09, 2015 11:46 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > Gronde, Christopher (Contractor) wrote: >> I restarted dirsrv and attempted to start krb5kdc and this is what >> the error log shows >> >> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >> operation threads >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop >> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 >> starting up >> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests > > Ok, that's good. > > I'd do something like this to see what is in the db (substitute example.com with your domain): > > $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b > cn=kerberos,dc=example,dc=com > > (don't post the output as it would include the kerberos master key). > > If that returns nothing that's bad. > > If it succeeds I'd broaden the search base a bit to see what data you > do > have: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b > cn=groups,cn=accounts,dc=example,dc=com > > I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. > > Let us know if either or both turns up nothing. > > rob > >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Monday, November 09, 2015 10:51 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> Hello all! >>> >>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>> >>> # service krb5kdc start >>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>> >>> # cat /var/log/krb5kdc.log >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> >>> I found this article online: >>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>> >>> Which stated it might be because The slave KDC does not have a stash >>> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >>> listed: >>> >>> # kdb5_util stash >>> kdb5_util: Server error while retrieving master entry >>> >>> No further information found on the proceeding error above for the kdb5_util command. >>> >>> Any thoughts? >> First: don't use instructions which are not related to IPA, please. >> >> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >> >> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >> >> -- >> / Alexander Bokovoy >> >> > > From abokovoy at redhat.com Mon Nov 9 20:44:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Nov 2015 22:44:38 +0200 Subject: [Freeipa-users] First tests against the REST/JSON API In-Reply-To: <5640DEE0.20107@doerr-privat.de> References: <5640DEE0.20107@doerr-privat.de> Message-ID: <20151109204438.GI1147@redhat.com> On Mon, 09 Nov 2015, Oliver D?rr wrote: >Hi, > >I'm completly new to this list and the product behind it. I'm trying >to use perl to get a list from my IPA installation of all users that >are on the server. > > > >#!/usr/bin/perl > >use strict; >use REST::Client; >use JSON; >use Data::Dumper; >use MIME::Base64; > >my $username="admin"; >my $password="secret"; >my $headers= { > 'Accept' => 'application/json', > 'Content-Type' => 'application/x-www-form-urlencoded', > 'Authorization' => 'Basic', > 'user' => encode_base64($username), > 'password' => encode_base64($password) > #encode_base64($username.":".$password) >}; > >my $client=REST::Client->new(); >$client->setHost("https://ipa.kreditwerk.de"); >$client->POST("/ipa/session/login_password", $headers); >print Dumper $client->responseContent(); > >Sadly I get back >$VAR1 = '500 Not a SCALAR reference >'; > > >I can't find any hinside the error log of the apache, even with debug >enabled. I can't find any thing in the internet that helps me. >(Perhaps I do not know where to look for). > >So any idea where I should look at it to troubleshoot this problem? You are doing it wrong :) Have you read my blog article? https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ You need to: - present referer pointing back to IPA server - use correct accept header as 'text/plain' for session password logon - pass username and password in the body of the request, not header, encoded ias form parameters 'user' and 'password' Attached is a simple example that works. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: dumpipa.pl Type: application/x-perl Size: 673 bytes Desc: not available URL: From brian at interlinx.bc.ca Mon Nov 9 21:55:27 2015 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 09 Nov 2015 16:55:27 -0500 Subject: [Freeipa-users] re-enrolling clients with --force-join getting /var/lib/sss/pubconf/known_hosts conflicts In-Reply-To: <563BC94D.5020301@redhat.com> References: <1446669474.22705.126.camel@interlinx.bc.ca> <1446758050.22705.177.camel@interlinx.bc.ca> <563BC94D.5020301@redhat.com> Message-ID: <1447106127.16711.53.camel@interlinx.bc.ca> On Thu, 2015-11-05 at 16:25 -0500, Rob Crittenden wrote: > What is "flaky" about it? It will fail and then without doing anything else except waiting a second or two, a second invocation will succeed. But I think I know why. It seems to fail on the slave server but pass on the primary server. Any hints on what to start looking for? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From natxo.asenjo at gmail.com Mon Nov 9 19:30:50 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 9 Nov 2015 20:30:50 +0100 Subject: [Freeipa-users] First tests against the REST/JSON API In-Reply-To: <5640DEE0.20107@doerr-privat.de> References: <5640DEE0.20107@doerr-privat.de> Message-ID: hi, On Mon, Nov 9, 2015 at 6:58 PM, Oliver D?rr wrote: > Hi, > > I'm completly new to this list and the product behind it. I'm trying to > use perl to get a list from my IPA installation of all users that are on > the server. > unfortunately I cannot help you right now, but have you taken a look at this blog post: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ It could give you some pointers. Share your code if you get it to work :-) Thanks. -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 10 08:14:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Nov 2015 10:14:38 +0200 Subject: [Freeipa-users] First tests against the REST/JSON API In-Reply-To: References: <5640DEE0.20107@doerr-privat.de> Message-ID: <20151110081438.GP1147@redhat.com> On Mon, 09 Nov 2015, Natxo Asenjo wrote: >hi, > >On Mon, Nov 9, 2015 at 6:58 PM, Oliver D?rr wrote: > >> Hi, >> >> I'm completly new to this list and the product behind it. I'm trying to >> use perl to get a list from my IPA installation of all users that are on >> the server. >> > >unfortunately I cannot help you right now, but have you taken a look at >this blog post: > >https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ > >It could give you some pointers. > >Share your code if you get it to work :-) The code in my response (see other mail) works fine, Oliver contacted me privately. Oliver, please respond to the list. :) -- / Alexander Bokovoy From Christopher.Gronde at fincen.gov Tue Nov 10 13:03:39 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 13:03:39 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56410155.2090009@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> When I tried to start the service again I got no response from tail of the log, but this is a repeating entry I see in the access log [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from to [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 Does anyone know what err=14 or err=49 are? -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, November 09, 2015 3:26 PM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > Nothing bad came back and there is definitely data in the tree. Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: 1. See if it is binding at all 2. See what the search is and what, if any, results were returned This would be in /var/log/dirsrv/slapd-YOUR_REALM/access rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, November 09, 2015 11:46 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > Gronde, Christopher (Contractor) wrote: >> I restarted dirsrv and attempted to start krb5kdc and this is what >> the error log shows >> >> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >> operation threads >> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >> internal subsystems and plugins >> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop >> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 >> starting up >> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests > > Ok, that's good. > > I'd do something like this to see what is in the db (substitute example.com with your domain): > > $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b > cn=kerberos,dc=example,dc=com > > (don't post the output as it would include the kerberos master key). > > If that returns nothing that's bad. > > If it succeeds I'd broaden the search base a bit to see what data you > do > have: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b > cn=groups,cn=accounts,dc=example,dc=com > > I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. > > Let us know if either or both turns up nothing. > > rob > >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Monday, November 09, 2015 10:51 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> Hello all! >>> >>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>> >>> # service krb5kdc start >>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>> >>> # cat /var/log/krb5kdc.log >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> krb5kdc: Server error - while fetching master key K/M for realm >>> ITMODEV.GOV >>> >>> I found this article online: >>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>> >>> Which stated it might be because The slave KDC does not have a stash >>> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >>> listed: >>> >>> # kdb5_util stash >>> kdb5_util: Server error while retrieving master entry >>> >>> No further information found on the proceeding error above for the kdb5_util command. >>> >>> Any thoughts? >> First: don't use instructions which are not related to IPA, please. >> >> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >> >> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >> >> -- >> / Alexander Bokovoy >> >> > > From abokovoy at redhat.com Tue Nov 10 13:18:14 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Nov 2015 15:18:14 +0200 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> Message-ID: <20151110131814.GS1147@redhat.com> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >When I tried to start the service again I got no response from tail of the log, but this is a repeating entry I see in the access log > >[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 >[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from to >[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress >[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress >[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 nentries=0 etime=0 >[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 > >Does anyone know what err=14 or err=49 are? err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. This is normal for SASL GSSAPI. err=49 is wrong password or username, i.e. credentials were incorrect. It may also mean that LDAP server side was unable to process Kerberos negotiation due to not having a current Kerberos ticket for own service (LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down. > >-----Original Message----- >From: Rob Crittenden [mailto:rcritten at redhat.com] >Sent: Monday, November 09, 2015 3:26 PM >To: Gronde, Christopher (Contractor) ; Alexander Bokovoy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > >Gronde, Christopher (Contractor) wrote: >> Nothing bad came back and there is definitely data in the tree. > >Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: > >1. See if it is binding at all >2. See what the search is and what, if any, results were returned > >This would be in /var/log/dirsrv/slapd-YOUR_REALM/access > >rob > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Monday, November 09, 2015 11:46 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> Gronde, Christopher (Contractor) wrote: >>> I restarted dirsrv and attempted to start krb5kdc and this is what >>> the error log shows >>> >>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>> operation threads >>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>> internal subsystems and plugins >>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop >>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 >>> starting up >>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >> >> Ok, that's good. >> >> I'd do something like this to see what is in the db (substitute example.com with your domain): >> >> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >> cn=kerberos,dc=example,dc=com >> >> (don't post the output as it would include the kerberos master key). >> >> If that returns nothing that's bad. >> >> If it succeeds I'd broaden the search base a bit to see what data you >> do >> have: >> >> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >> cn=groups,cn=accounts,dc=example,dc=com >> >> I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. >> >> Let us know if either or both turns up nothing. >> >> rob >> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Monday, November 09, 2015 10:51 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> Hello all! >>>> >>>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>>> >>>> # service krb5kdc start >>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>>> >>>> # cat /var/log/krb5kdc.log >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> >>>> I found this article online: >>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>> >>>> Which stated it might be because The slave KDC does not have a stash >>>> file (.k5.EXAMPLE.COM). You need to create one. Tried the command >>>> listed: >>>> >>>> # kdb5_util stash >>>> kdb5_util: Server error while retrieving master entry >>>> >>>> No further information found on the proceeding error above for the kdb5_util command. >>>> >>>> Any thoughts? >>> First: don't use instructions which are not related to IPA, please. >>> >>> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >>> >>> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> > > -- / Alexander Bokovoy From Christopher.Gronde at fincen.gov Tue Nov 10 13:21:06 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 13:21:06 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <20151110131814.GS1147@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> Where can I verify or change the credentials it is trying to use? Is it my LDAP password? -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, November 10, 2015 8:18 AM To: Gronde, Christopher (Contractor) Cc: Rob Crittenden ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >When I tried to start the service again I got no response from tail of >the log, but this is a repeating entry I see in the access log > >[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >127.0.0.1 to 127.0.0.1 >[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from > to >[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >nentries=0 etime=0, SASL bind in progress >[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >nentries=0 etime=0, SASL bind in progress >[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >version=3 mech=GSSAPI >[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >nentries=0 etime=0 >[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 > >Does anyone know what err=14 or err=49 are? err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. This is normal for SASL GSSAPI. err=49 is wrong password or username, i.e. credentials were incorrect. It may also mean that LDAP server side was unable to process Kerberos negotiation due to not having a current Kerberos ticket for own service (LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down. > >-----Original Message----- >From: Rob Crittenden [mailto:rcritten at redhat.com] >Sent: Monday, November 09, 2015 3:26 PM >To: Gronde, Christopher (Contractor) ; >Alexander Bokovoy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >authentication error) > >Gronde, Christopher (Contractor) wrote: >> Nothing bad came back and there is definitely data in the tree. > >Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: > >1. See if it is binding at all >2. See what the search is and what, if any, results were returned > >This would be in /var/log/dirsrv/slapd-YOUR_REALM/access > >rob > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Monday, November 09, 2015 11:46 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> Gronde, Christopher (Contractor) wrote: >>> I restarted dirsrv and attempted to start krb5kdc and this is what >>> the error log shows >>> >>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>> operation threads >>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>> internal subsystems and plugins >>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>> stop >>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>> B2015.247.1737 starting up >>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >> >> Ok, that's good. >> >> I'd do something like this to see what is in the db (substitute example.com with your domain): >> >> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >> cn=kerberos,dc=example,dc=com >> >> (don't post the output as it would include the kerberos master key). >> >> If that returns nothing that's bad. >> >> If it succeeds I'd broaden the search base a bit to see what data you >> do >> have: >> >> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >> cn=groups,cn=accounts,dc=example,dc=com >> >> I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. >> >> Let us know if either or both turns up nothing. >> >> rob >> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Monday, November 09, 2015 10:51 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> Hello all! >>>> >>>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>>> >>>> # service krb5kdc start >>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>>> >>>> # cat /var/log/krb5kdc.log >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> krb5kdc: Server error - while fetching master key K/M for realm >>>> ITMODEV.GOV >>>> >>>> I found this article online: >>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>> >>>> Which stated it might be because The slave KDC does not have a >>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>> command >>>> listed: >>>> >>>> # kdb5_util stash >>>> kdb5_util: Server error while retrieving master entry >>>> >>>> No further information found on the proceeding error above for the kdb5_util command. >>>> >>>> Any thoughts? >>> First: don't use instructions which are not related to IPA, please. >>> >>> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >>> >>> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> > > -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 10 13:40:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Nov 2015 15:40:33 +0200 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> Message-ID: <20151110134033.GT1147@redhat.com> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >Where can I verify or change the credentials it is trying to use? Is it my LDAP password? No, according to your logs, it is your LDAP master trying to replicate (push changes) to your LDAP replica: >>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from to >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI If that is true, it would be ldap/ Kerberos principal talking to ldap/ Kerberos principal. If that fails, it means master and replica KDCs have different understanding of both ldap/ and ldap/ keys which most likely means keys were rotated on master and weren't propagated to replica. How to solve it? One possibility is to set master's hostname as KDC address in krb5.conf on replica, forcing LDAP server on replica to use master's KDC. I'm absolutely not sure this will actually work but at least it allows to see if we are indeed dealing with inconsistent state of service principals' keys. > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, November 10, 2015 8:18 AM >To: Gronde, Christopher (Contractor) >Cc: Rob Crittenden ; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > >On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>When I tried to start the service again I got no response from tail of >>the log, but this is a repeating entry I see in the access log >> >>[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>127.0.0.1 to 127.0.0.1 >>[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >> to >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>nentries=0 etime=0, SASL bind in progress >>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>nentries=0 etime=0, SASL bind in progress >>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>nentries=0 etime=0 >>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >> >>Does anyone know what err=14 or err=49 are? >err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. This is normal for SASL GSSAPI. > >err=49 is wrong password or username, i.e. credentials were incorrect. >It may also mean that LDAP server side was unable to process Kerberos negotiation due to not having a current Kerberos ticket for own service >(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down. > >> >>-----Original Message----- >>From: Rob Crittenden [mailto:rcritten at redhat.com] >>Sent: Monday, November 09, 2015 3:26 PM >>To: Gronde, Christopher (Contractor) ; >>Alexander Bokovoy >>Cc: freeipa-users at redhat.com >>Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>authentication error) >> >>Gronde, Christopher (Contractor) wrote: >>> Nothing bad came back and there is definitely data in the tree. >> >>Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: >> >>1. See if it is binding at all >>2. See what the search is and what, if any, results were returned >> >>This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >> >>rob >> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Monday, November 09, 2015 11:46 AM >>> To: Gronde, Christopher (Contractor) ; >>> Alexander Bokovoy >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> I restarted dirsrv and attempted to start krb5kdc and this is what >>>> the error log shows >>>> >>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests >>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>> operation threads >>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>> internal subsystems and plugins >>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>> stop >>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>> B2015.247.1737 starting up >>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests >>> >>> Ok, that's good. >>> >>> I'd do something like this to see what is in the db (substitute example.com with your domain): >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>> cn=kerberos,dc=example,dc=com >>> >>> (don't post the output as it would include the kerberos master key). >>> >>> If that returns nothing that's bad. >>> >>> If it succeeds I'd broaden the search base a bit to see what data you >>> do >>> have: >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=groups,cn=accounts,dc=example,dc=com >>> >>> I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. >>> >>> Let us know if either or both turns up nothing. >>> >>> rob >>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Monday, November 09, 2015 10:51 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> Hello all! >>>>> >>>>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>>>> >>>>> # service krb5kdc start >>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>>>> >>>>> # cat /var/log/krb5kdc.log >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> >>>>> I found this article online: >>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>> >>>>> Which stated it might be because The slave KDC does not have a >>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>> command >>>>> listed: >>>>> >>>>> # kdb5_util stash >>>>> kdb5_util: Server error while retrieving master entry >>>>> >>>>> No further information found on the proceeding error above for the kdb5_util command. >>>>> >>>>> Any thoughts? >>>> First: don't use instructions which are not related to IPA, please. >>>> >>>> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >>>> >>>> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >> >> > >-- >/ Alexander Bokovoy > -- / Alexander Bokovoy From lkrispen at redhat.com Tue Nov 10 14:03:00 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 15:03:00 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <20151110134033.GT1147@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> Message-ID: <5641F914.7040600@redhat.com> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: > On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >> Where can I verify or change the credentials it is trying to use? Is >> it my LDAP password? > No, according to your logs, it is your LDAP master trying to replicate > (push changes) to your LDAP replica: >>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>> to >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. Set nsslapd-acesslog-level: 260 and then look what internal searches are done during the gssapi authentication > > If that is true, it would be ldap/ Kerberos principal talking to > ldap/ Kerberos principal. If that fails, it means master and > replica KDCs have different understanding of both ldap/ and > ldap/ keys which most likely means keys were rotated on master > and weren't propagated to replica. > > How to solve it? One possibility is to set master's hostname as KDC > address in krb5.conf on replica, forcing LDAP server on replica to use > master's KDC. I'm absolutely not sure this will actually work but at > least it allows to see if we are indeed dealing with inconsistent state > of service principals' keys. > >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, November 10, 2015 8:18 AM >> To: Gronde, Christopher (Contractor) >> Cc: Rob Crittenden ; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> When I tried to start the service again I got no response from tail of >>> the log, but this is a repeating entry I see in the access log >>> >>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>> 127.0.0.1 to 127.0.0.1 >>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>> to >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>> nentries=0 etime=0 >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>> >>> Does anyone know what err=14 or err=49 are? >> err=14 means SASL bind in progress -- i.e. multi-round processing is >> ongoing. This is normal for SASL GSSAPI. >> >> err=49 is wrong password or username, i.e. credentials were incorrect. >> It may also mean that LDAP server side was unable to process Kerberos >> negotiation due to not having a current Kerberos ticket for own service >> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >> KDC is down. >> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Monday, November 09, 2015 3:26 PM >>> To: Gronde, Christopher (Contractor) ; >>> Alexander Bokovoy >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Nothing bad came back and there is definitely data in the tree. >>> >>> Ok, I guess I'd try to start the kdc again and then watch the 389-ds >>> access log (buffered) to: >>> >>> 1. See if it is binding at all >>> 2. See what the search is and what, if any, results were returned >>> >>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>> >>> rob >>> >>>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Monday, November 09, 2015 11:46 AM >>>> To: Gronde, Christopher (Contractor) ; >>>> Alexander Bokovoy >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> I restarted dirsrv and attempted to start krb5kdc and this is what >>>>> the error log shows >>>>> >>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size >>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>> the entry cache size nsslapd-cachememsize. >>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>> Interfaces port 389 for LDAP requests >>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>> operation threads >>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>> internal subsystems and plugins >>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>> stop >>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>> B2015.247.1737 starting up >>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size >>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>> the entry cache size nsslapd-cachememsize. >>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>> Interfaces port 389 for LDAP requests >>>> >>>> Ok, that's good. >>>> >>>> I'd do something like this to see what is in the db (substitute >>>> example.com with your domain): >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>> cn=kerberos,dc=example,dc=com >>>> >>>> (don't post the output as it would include the kerberos master key). >>>> >>>> If that returns nothing that's bad. >>>> >>>> If it succeeds I'd broaden the search base a bit to see what data you >>>> do >>>> have: >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=groups,cn=accounts,dc=example,dc=com >>>> >>>> I picked groups because usually groups << users in numbers. This is >>>> just to see if you have data in the tree. >>>> >>>> Let us know if either or both turns up nothing. >>>> >>>> rob >>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> Hello all! >>>>>> >>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>> going on for sometime, I have all my certs figured out but the >>>>>> krb5kdc service will not start. >>>>>> >>>>>> # service krb5kdc start >>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>> >>>>>> # cat /var/log/krb5kdc.log >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> >>>>>> I found this article online: >>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>> >>>>>> Which stated it might be because The slave KDC does not have a >>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>> command >>>>>> listed: >>>>>> >>>>>> # kdb5_util stash >>>>>> kdb5_util: Server error while retrieving master entry >>>>>> >>>>>> No further information found on the proceeding error above for >>>>>> the kdb5_util command. >>>>>> >>>>>> Any thoughts? >>>>> First: don't use instructions which are not related to IPA, please. >>>>> >>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>> anything else do not apply here at all. >>>>> >>>>> If you see 'Server error - while fetching master key ..' it means >>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>> server work on the replica? What is in its error log >>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>> >>>> >>> >>> >> >> -- >> / Alexander Bokovoy >> > From Christopher.Gronde at fincen.gov Tue Nov 10 13:56:55 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 13:56:55 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <20151110134033.GT1147@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BD4D@hqexdb01.hqfincen.gov> So I changed the hostnames in krb5.conf [realms] = { kdc = :88 master_kdc = :88 admin_server = :749 default_domain = pkinit_anchors = FILE:/etc/ipa/ca.crt } Service still will not start however now in the access log instead of showing the connection from master to replica it shows replica to replica [10/Nov/2015:08:51:03 -0500] conn=52 op=3 UNBIND [10/Nov/2015:08:51:03 -0500] conn=52 op=3 fd=64 closed - U1 [10/Nov/2015:08:51:03 -0500] conn=52 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2015:08:51:05 -0500] conn=53 fd=64 slot=64 connection from to [10/Nov/2015:08:51:05 -0500] conn=53 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:08:51:05 -0500] conn=53 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:08:51:05 -0500] conn=53 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2015:08:51:05 -0500] conn=53 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:08:51:05 -0500] conn=53 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [10/Nov/2015:08:51:05 -0500] conn=53 op=3 UNBIND [10/Nov/2015:08:51:05 -0500] conn=53 op=3 fd=64 closed - U1 [10/Nov/2015:08:51:05 -0500] conn=53 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Tuesday, November 10, 2015 8:41 AM To: Gronde, Christopher (Contractor) Cc: Rob Crittenden ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >Where can I verify or change the credentials it is trying to use? Is it my LDAP password? No, according to your logs, it is your LDAP master trying to replicate (push changes) to your LDAP replica: >>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >> to >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>version=3 mech=GSSAPI If that is true, it would be ldap/ Kerberos principal talking to ldap/ Kerberos principal. If that fails, it means master and replica KDCs have different understanding of both ldap/ and ldap/ keys which most likely means keys were rotated on master and weren't propagated to replica. How to solve it? One possibility is to set master's hostname as KDC address in krb5.conf on replica, forcing LDAP server on replica to use master's KDC. I'm absolutely not sure this will actually work but at least it allows to see if we are indeed dealing with inconsistent state of service principals' keys. > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Tuesday, November 10, 2015 8:18 AM >To: Gronde, Christopher (Contractor) >Cc: Rob Crittenden ; freeipa-users at redhat.com >Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >authentication error) > >On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>When I tried to start the service again I got no response from tail of >>the log, but this is a repeating entry I see in the access log >> >>[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>127.0.0.1 to 127.0.0.1 >>[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >> to >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>nentries=0 etime=0, SASL bind in progress >>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>nentries=0 etime=0, SASL bind in progress >>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>version=3 mech=GSSAPI >>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>nentries=0 etime=0 >>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >> >>Does anyone know what err=14 or err=49 are? >err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. This is normal for SASL GSSAPI. > >err=49 is wrong password or username, i.e. credentials were incorrect. >It may also mean that LDAP server side was unable to process Kerberos >negotiation due to not having a current Kerberos ticket for own service >(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down. > >> >>-----Original Message----- >>From: Rob Crittenden [mailto:rcritten at redhat.com] >>Sent: Monday, November 09, 2015 3:26 PM >>To: Gronde, Christopher (Contractor) ; >>Alexander Bokovoy >>Cc: freeipa-users at redhat.com >>Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>authentication error) >> >>Gronde, Christopher (Contractor) wrote: >>> Nothing bad came back and there is definitely data in the tree. >> >>Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log (buffered) to: >> >>1. See if it is binding at all >>2. See what the search is and what, if any, results were returned >> >>This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >> >>rob >> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Monday, November 09, 2015 11:46 AM >>> To: Gronde, Christopher (Contractor) >>> ; Alexander Bokovoy >>> >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> I restarted dirsrv and attempted to start krb5kdc and this is what >>>> the error log shows >>>> >>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests >>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>> operation threads >>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>> internal subsystems and plugins >>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>> stop >>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>> B2015.247.1737 starting up >>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. >>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests >>> >>> Ok, that's good. >>> >>> I'd do something like this to see what is in the db (substitute example.com with your domain): >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>> cn=kerberos,dc=example,dc=com >>> >>> (don't post the output as it would include the kerberos master key). >>> >>> If that returns nothing that's bad. >>> >>> If it succeeds I'd broaden the search base a bit to see what data >>> you do >>> have: >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=groups,cn=accounts,dc=example,dc=com >>> >>> I picked groups because usually groups << users in numbers. This is just to see if you have data in the tree. >>> >>> Let us know if either or both turns up nothing. >>> >>> rob >>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Monday, November 09, 2015 10:51 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> Hello all! >>>>> >>>>> On my replica IPA server after fixing a cert issue that had been going on for sometime, I have all my certs figured out but the krb5kdc service will not start. >>>>> >>>>> # service krb5kdc start >>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see log file for details [FAILED] >>>>> >>>>> # cat /var/log/krb5kdc.log >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>> ITMODEV.GOV >>>>> >>>>> I found this article online: >>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>> >>>>> Which stated it might be because The slave KDC does not have a >>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>> command >>>>> listed: >>>>> >>>>> # kdb5_util stash >>>>> kdb5_util: Server error while retrieving master entry >>>>> >>>>> No further information found on the proceeding error above for the kdb5_util command. >>>>> >>>>> Any thoughts? >>>> First: don't use instructions which are not related to IPA, please. >>>> >>>> FreeIPA has its own LDAP driver for KDC and instructions for anything else do not apply here at all. >>>> >>>> If you see 'Server error - while fetching master key ..' it means KDC LDAP driver was unable to contact LDAP server. Does LDAP server work on the replica? What is in its error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >> >> > >-- >/ Alexander Bokovoy > -- / Alexander Bokovoy From d.korittki at mittwald.de Tue Nov 10 13:59:45 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Tue, 10 Nov 2015 14:59:45 +0100 Subject: [Freeipa-users] ipa-getkeytab missing permissions after migration Message-ID: <5641F851.1070908@mittwald.de> Hello folks, I created a replica IPA host with version 4.1.0-18.el7.centos.4, while the initial master is a FreeIPA 3.3.3. Everything seems to work fine with the new host except for one thing: We have a special IPA user, which has the rights for managing and enrolling hosts. I am able to add hosts with this user, but ipa-getkeytab command returns the following message: root at ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p "host/testhost.internal" -k testhost.internal.keytab Failed to parse result: Insufficient access rights The keytab was successfully created, though. dirsrv error logs showed me this after raising log level: [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=590 op=3 binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny write on entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys) to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the subject by aci(53): aciname= "Entities are allowed to rekey managed entries", acidn="cn=accounts,dc=internal" [10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file ipa_pwd_extop.c, line 756]: slapi_access_allowed does not allow WRITE to ipaProtectedOperation;write_keys! [10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, line 1630]: Not allowed to set keytab on [host/testhost.internal at INTERNAL]! [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3 binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow write on entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) to uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by aci(277): aciname= "permission:System: Manage Host Keytab", acidn="cn=computers,cn=accounts,dc=internal" So it seems he can't find a proper write permission for ipaProtectedOperation;write_keys. When creating a permission with write access to this attribute everything works fine, but should'nt there already be a proper permission? I discovered the following permission: root at ipa01:~ > ipa permission-show --all --raw 'System: Manage Host Keytab Permissions' dn: cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=internal cn: System: Manage Host Keytab Permissions ipapermright: write ipapermright: read ipapermright: compare ipapermright: search ipapermincludedattr: createtimestamp ipapermincludedattr: modifytimestamp ipapermincludedattr: entryusn ipapermdefaultattr: objectclass ipapermdefaultattr: ipaallowedtoperform;write_keys ipapermdefaultattr: ipaallowedtoperform;read_keys ipapermbindruletype: permission ipapermlocation: cn=computers,cn=accounts,dc=internal ipapermtargetfilter: (objectclass=ipahost) member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=internal";) ipapermissiontype: V2 ipapermissiontype: MANAGED ipapermissiontype: SYSTEM memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal objectclass: ipapermission objectclass: top objectclass: groupofnames objectclass: ipapermissionv2 So there is a aci with write access on ipaallowedtoperform;write_keys, but not on ipaProtectedOperation;write_keys. So the question is: Has something gone wrong while migrating the aci's to freeipa v4 style? If yes, how can I fix it? Dominik Korittki From Christopher.Gronde at fincen.gov Tue Nov 10 14:32:00 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 14:32:00 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <5641F914.7040600@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> How do I change that log setting? Is that done in LDAP? Using ldapmodify? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz Sent: Tuesday, November 10, 2015 9:03 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: > On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >> Where can I verify or change the credentials it is trying to use? Is >> it my LDAP password? > No, according to your logs, it is your LDAP master trying to replicate > (push changes) to your LDAP replica: >>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>> to >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. Set nsslapd-acesslog-level: 260 and then look what internal searches are done during the gssapi authentication > > If that is true, it would be ldap/ Kerberos principal talking > to ldap/ Kerberos principal. If that fails, it means master > and replica KDCs have different understanding of both ldap/ > and ldap/ keys which most likely means keys were rotated on > master and weren't propagated to replica. > > How to solve it? One possibility is to set master's hostname as KDC > address in krb5.conf on replica, forcing LDAP server on replica to use > master's KDC. I'm absolutely not sure this will actually work but at > least it allows to see if we are indeed dealing with inconsistent > state of service principals' keys. > >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Tuesday, November 10, 2015 8:18 AM >> To: Gronde, Christopher (Contractor) >> Cc: Rob Crittenden ; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> When I tried to start the service again I got no response from tail >>> of the log, but this is a repeating entry I see in the access log >>> >>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>> 127.0.0.1 to 127.0.0.1 >>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>> to >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>> nentries=0 etime=0 >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>> >>> Does anyone know what err=14 or err=49 are? >> err=14 means SASL bind in progress -- i.e. multi-round processing is >> ongoing. This is normal for SASL GSSAPI. >> >> err=49 is wrong password or username, i.e. credentials were incorrect. >> It may also mean that LDAP server side was unable to process Kerberos >> negotiation due to not having a current Kerberos ticket for own >> service >> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >> KDC is down. >> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Monday, November 09, 2015 3:26 PM >>> To: Gronde, Christopher (Contractor) >>> ; Alexander Bokovoy >>> >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Nothing bad came back and there is definitely data in the tree. >>> >>> Ok, I guess I'd try to start the kdc again and then watch the 389-ds >>> access log (buffered) to: >>> >>> 1. See if it is binding at all >>> 2. See what the search is and what, if any, results were returned >>> >>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>> >>> rob >>> >>>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Monday, November 09, 2015 11:46 AM >>>> To: Gronde, Christopher (Contractor) >>>> ; Alexander Bokovoy >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> I restarted dirsrv and attempted to start krb5kdc and this is what >>>>> the error log shows >>>>> >>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size >>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>> the entry cache size nsslapd-cachememsize. >>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>> Interfaces port 389 for LDAP requests >>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>> operation threads >>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>> internal subsystems and plugins >>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>> stop >>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>> B2015.247.1737 starting up >>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size >>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>> the entry cache size nsslapd-cachememsize. >>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>> Interfaces port 389 for LDAP requests >>>> >>>> Ok, that's good. >>>> >>>> I'd do something like this to see what is in the db (substitute >>>> example.com with your domain): >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>> cn=kerberos,dc=example,dc=com >>>> >>>> (don't post the output as it would include the kerberos master key). >>>> >>>> If that returns nothing that's bad. >>>> >>>> If it succeeds I'd broaden the search base a bit to see what data >>>> you do >>>> have: >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=groups,cn=accounts,dc=example,dc=com >>>> >>>> I picked groups because usually groups << users in numbers. This is >>>> just to see if you have data in the tree. >>>> >>>> Let us know if either or both turns up nothing. >>>> >>>> rob >>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> Hello all! >>>>>> >>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>> going on for sometime, I have all my certs figured out but the >>>>>> krb5kdc service will not start. >>>>>> >>>>>> # service krb5kdc start >>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>> >>>>>> # cat /var/log/krb5kdc.log >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>> ITMODEV.GOV >>>>>> >>>>>> I found this article online: >>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>> >>>>>> Which stated it might be because The slave KDC does not have a >>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>> command >>>>>> listed: >>>>>> >>>>>> # kdb5_util stash >>>>>> kdb5_util: Server error while retrieving master entry >>>>>> >>>>>> No further information found on the proceeding error above for >>>>>> the kdb5_util command. >>>>>> >>>>>> Any thoughts? >>>>> First: don't use instructions which are not related to IPA, please. >>>>> >>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>> anything else do not apply here at all. >>>>> >>>>> If you see 'Server error - while fetching master key ..' it means >>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>> server work on the replica? What is in its error log >>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>> >>>> >>> >>> >> >> -- >> / 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 From lkrispen at redhat.com Tue Nov 10 14:47:38 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 15:47:38 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> Message-ID: <5642038A.5050505@redhat.com> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: > How do I change that log setting? Is that done in LDAP? Using ldapmodify? yes, ldapmodify ... dn: cn=config changetype: modify replace: nsslapd-acesslog-level nsslapd-acesslog-level: 260 > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, November 10, 2015 9:03 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > > On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> Where can I verify or change the credentials it is trying to use? Is >>> it my LDAP password? >> No, according to your logs, it is your LDAP master trying to replicate >> (push changes) to your LDAP replica: >>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>> to >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI > err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. > Set nsslapd-acesslog-level: 260 > > and then look what internal searches are done during the gssapi authentication >> If that is true, it would be ldap/ Kerberos principal talking >> to ldap/ Kerberos principal. If that fails, it means master >> and replica KDCs have different understanding of both ldap/ >> and ldap/ keys which most likely means keys were rotated on >> master and weren't propagated to replica. >> >> How to solve it? One possibility is to set master's hostname as KDC >> address in krb5.conf on replica, forcing LDAP server on replica to use >> master's KDC. I'm absolutely not sure this will actually work but at >> least it allows to see if we are indeed dealing with inconsistent >> state of service principals' keys. >> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Tuesday, November 10, 2015 8:18 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> When I tried to start the service again I got no response from tail >>>> of the log, but this is a repeating entry I see in the access log >>>> >>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>> 127.0.0.1 to 127.0.0.1 >>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>> to >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>> nentries=0 etime=0 >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>> >>>> Does anyone know what err=14 or err=49 are? >>> err=14 means SASL bind in progress -- i.e. multi-round processing is >>> ongoing. This is normal for SASL GSSAPI. >>> >>> err=49 is wrong password or username, i.e. credentials were incorrect. >>> It may also mean that LDAP server side was unable to process Kerberos >>> negotiation due to not having a current Kerberos ticket for own >>> service >>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>> KDC is down. >>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Monday, November 09, 2015 3:26 PM >>>> To: Gronde, Christopher (Contractor) >>>> ; Alexander Bokovoy >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> Nothing bad came back and there is definitely data in the tree. >>>> Ok, I guess I'd try to start the kdc again and then watch the 389-ds >>>> access log (buffered) to: >>>> >>>> 1. See if it is binding at all >>>> 2. See what the search is and what, if any, results were returned >>>> >>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>> >>>> rob >>>> >>>>> -----Original Message----- >>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> ; Alexander Bokovoy >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> Gronde, Christopher (Contractor) wrote: >>>>>> I restarted dirsrv and attempted to start krb5kdc and this is what >>>>>> the error log shows >>>>>> >>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size >>>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>>> the entry cache size nsslapd-cachememsize. >>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>> Interfaces port 389 for LDAP requests >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>> operation threads >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>>> internal subsystems and plugins >>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>> stop >>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>> B2015.247.1737 starting up >>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size >>>>>> 10485760B is less than db size 28016640B; We recommend to increase >>>>>> the entry cache size nsslapd-cachememsize. >>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>> Interfaces port 389 for LDAP requests >>>>> Ok, that's good. >>>>> >>>>> I'd do something like this to see what is in the db (substitute >>>>> example.com with your domain): >>>>> >>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>> cn=kerberos,dc=example,dc=com >>>>> >>>>> (don't post the output as it would include the kerberos master key). >>>>> >>>>> If that returns nothing that's bad. >>>>> >>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>> you do >>>>> have: >>>>> >>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>> >>>>> I picked groups because usually groups << users in numbers. This is >>>>> just to see if you have data in the tree. >>>>> >>>>> Let us know if either or both turns up nothing. >>>>> >>>>> rob >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Hello all! >>>>>>> >>>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>>> going on for sometime, I have all my certs figured out but the >>>>>>> krb5kdc service will not start. >>>>>>> >>>>>>> # service krb5kdc start >>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>> >>>>>>> # cat /var/log/krb5kdc.log >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> >>>>>>> I found this article online: >>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>> >>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>> command >>>>>>> listed: >>>>>>> >>>>>>> # kdb5_util stash >>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>> >>>>>>> No further information found on the proceeding error above for >>>>>>> the kdb5_util command. >>>>>>> >>>>>>> Any thoughts? >>>>>> First: don't use instructions which are not related to IPA, please. >>>>>> >>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>> anything else do not apply here at all. >>>>>> >>>>>> If you see 'Server error - while fetching master key ..' it means >>>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>>> server work on the replica? What is in its error log >>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> >>>>>> >>>>> >>>> >>> -- >>> / 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 > From oliver at doerr-privat.de Tue Nov 10 14:53:53 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Tue, 10 Nov 2015 15:53:53 +0100 Subject: [Freeipa-users] First tests against the REST/JSON API In-Reply-To: <20151110081438.GP1147@redhat.com> References: <5640DEE0.20107@doerr-privat.de> <20151110081438.GP1147@redhat.com> Message-ID: <56420501.2060809@doerr-privat.de> Hi Alexander, sorry for responding you privately. This was not my intention; I just recognized that my mail program has two reply buttons (replay and reply to mailing list). I've played a bit around with your code and implemented a small Perl module and a test script. They both work in my environment, however I'm still not happy with them. What I don't like is... 1st, I need to provide my client version 2nd, I get the message 'truncated' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) from the user_find API 3rd, I do not know what the id is used for and so I'm unsure if I could automatically handle it in my Perl module However they should be a help for others who wants use Perl-script to access IPA-API. Anyway thanks for your help. This was what I need to get on the track. Oliver Am 10.11.2015 um 09:14 schrieb Alexander Bokovoy: > On Mon, 09 Nov 2015, Natxo Asenjo wrote: >> hi, >> >> On Mon, Nov 9, 2015 at 6:58 PM, Oliver D?rr >> wrote: >> >>> Hi, >>> >>> I'm completly new to this list and the product behind it. I'm trying to >>> use perl to get a list from my IPA installation of all users that >>> are on >>> the server. >>> >> >> unfortunately I cannot help you right now, but have you taken a look at >> this blog post: >> >> https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ >> >> It could give you some pointers. >> >> Share your code if you get it to work :-) > The code in my response (see other mail) works fine, Oliver contacted me > privately. > > Oliver, please respond to the list. :) -------------- next part -------------- package freeipa; use strict; use REST::Client; use JSON; use Data::Dumper; our $VERSION="0.0.1"; BEGIN { }; sub new # Constructor of the class freeipa { my ($Class)=@_; my $self= {}; bless($self,$Class); $self->{'id'}=0; return $self; } # sub news sub set # Setter of the class freeipa. At this moment only usuable or scalar values { my $ipaObj=shift; my $scalar=shift; my $value=shift; $ipaObj->{$scalar}=$value; } # sub set sub connect # Connects to the specified IPA server { my $ipaObj=shift; my $headers = { 'Accept' => 'text/plain', 'Content-Type' => 'application/x-www-form-urlencoded', 'Referer' => $ipaObj->{'baseUrl'} }; # my $headers my $client=REST::Client->new(); my $params = $client->buildQuery({'user' => $ipaObj->{'user'}, 'password' => $ipaObj->{'password'} }); $client->setHost($ipaObj->{'baseUrl'}); $client->POST("/ipa/session/login_password", substr($params,1), $headers); $ipaObj->{'authCookie'} = $client->responseHeader('Set-Cookie'); $ipaObj->{'restClient'}=$client; } # sub connect sub ipaMethod # Calls an API method against the IPA connection { my $ipaObj=shift; my $hashRef=shift; my $data = { 'id'=>$ipaObj->{'id'}, 'params' => [ [], { 'version' => $ipaObj->{'version'} } ] }; # my $data $ipaObj->{'id'}++; my $headers = { 'Accept' => 'text/plain', 'Content-Type' => 'application/json', 'Cookie' => $ipaObj->{'authCookie'}, 'Referer' => $ipaObj->{'baseUrl'}."/ipa/session/json" }; # Copy the specified part of the method over the default data defined in $data foreach my $var (keys (%{$hashRef})) { $data->{$var}=$hashRef->{$var}; } # Format the method and data to json and make a REST request against the IPA server my $jsonMethod = to_json($data); $ipaObj->{'restClient'}->POST("/ipa/session/json", $jsonMethod, $headers); # bring the JSON-formed response into perl objects... my $restRet=from_json($ipaObj->{'restClient'}->responseContent()); # ... and return ist return $restRet; } # sub ipaMethod -------------- next part -------------- A non-text attachment was scrubbed... Name: testConnection.pl Type: application/x-perl Size: 927 bytes Desc: not available URL: From Christopher.Gronde at fincen.gov Tue Nov 10 14:53:45 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 14:53:45 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <5642038A.5050505@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> Ran into an error trying to set that # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: dn: cn=config changetype: modify replace: nsslapd-acesslog-level nsslapd-acesslog-level: 260 modifying entry "cn=config" ldap_modify: Server is unwilling to perform (53) additional info: Unknown attribute nsslapd-acesslog-level will be ignored [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP Password: ldap_bind: Inappropriate authentication (48) -----Original Message----- From: Ludwig Krispenz [mailto:lkrispen at redhat.com] Sent: Tuesday, November 10, 2015 9:48 AM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: > How do I change that log setting? Is that done in LDAP? Using ldapmodify? yes, ldapmodify ... dn: cn=config changetype: modify replace: nsslapd-acesslog-level nsslapd-acesslog-level: 260 > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, November 10, 2015 9:03 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > > On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>> Where can I verify or change the credentials it is trying to use? >>> Is it my LDAP password? >> No, according to your logs, it is your LDAP master trying to >> replicate (push changes) to your LDAP replica: >>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>> to >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI > err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. > Set nsslapd-acesslog-level: 260 > > and then look what internal searches are done during the gssapi > authentication >> If that is true, it would be ldap/ Kerberos principal talking >> to ldap/ Kerberos principal. If that fails, it means master >> and replica KDCs have different understanding of both ldap/ >> and ldap/ keys which most likely means keys were rotated on >> master and weren't propagated to replica. >> >> How to solve it? One possibility is to set master's hostname as KDC >> address in krb5.conf on replica, forcing LDAP server on replica to >> use master's KDC. I'm absolutely not sure this will actually work but >> at least it allows to see if we are indeed dealing with inconsistent >> state of service principals' keys. >> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Tuesday, November 10, 2015 8:18 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> When I tried to start the service again I got no response from tail >>>> of the log, but this is a repeating entry I see in the access log >>>> >>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>> 127.0.0.1 to 127.0.0.1 >>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>> to >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>> nentries=0 etime=0 >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>> >>>> Does anyone know what err=14 or err=49 are? >>> err=14 means SASL bind in progress -- i.e. multi-round processing is >>> ongoing. This is normal for SASL GSSAPI. >>> >>> err=49 is wrong password or username, i.e. credentials were incorrect. >>> It may also mean that LDAP server side was unable to process >>> Kerberos negotiation due to not having a current Kerberos ticket for >>> own service >>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>> KDC is down. >>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Monday, November 09, 2015 3:26 PM >>>> To: Gronde, Christopher (Contractor) >>>> ; Alexander Bokovoy >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> Nothing bad came back and there is definitely data in the tree. >>>> Ok, I guess I'd try to start the kdc again and then watch the >>>> 389-ds access log (buffered) to: >>>> >>>> 1. See if it is binding at all >>>> 2. See what the search is and what, if any, results were returned >>>> >>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>> >>>> rob >>>> >>>>> -----Original Message----- >>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> ; Alexander Bokovoy >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> Gronde, Christopher (Contractor) wrote: >>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>> what the error log shows >>>>>> >>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>> Interfaces port 389 for LDAP requests >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>> operation threads >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>>> internal subsystems and plugins >>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>> stop >>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>> B2015.247.1737 starting up >>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>> Interfaces port 389 for LDAP requests >>>>> Ok, that's good. >>>>> >>>>> I'd do something like this to see what is in the db (substitute >>>>> example.com with your domain): >>>>> >>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>> cn=kerberos,dc=example,dc=com >>>>> >>>>> (don't post the output as it would include the kerberos master key). >>>>> >>>>> If that returns nothing that's bad. >>>>> >>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>> you do >>>>> have: >>>>> >>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>> >>>>> I picked groups because usually groups << users in numbers. This >>>>> is just to see if you have data in the tree. >>>>> >>>>> Let us know if either or both turns up nothing. >>>>> >>>>> rob >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Hello all! >>>>>>> >>>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>>> going on for sometime, I have all my certs figured out but the >>>>>>> krb5kdc service will not start. >>>>>>> >>>>>>> # service krb5kdc start >>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>> >>>>>>> # cat /var/log/krb5kdc.log >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>> ITMODEV.GOV >>>>>>> >>>>>>> I found this article online: >>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>> >>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>> command >>>>>>> listed: >>>>>>> >>>>>>> # kdb5_util stash >>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>> >>>>>>> No further information found on the proceeding error above for >>>>>>> the kdb5_util command. >>>>>>> >>>>>>> Any thoughts? >>>>>> First: don't use instructions which are not related to IPA, please. >>>>>> >>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>> anything else do not apply here at all. >>>>>> >>>>>> If you see 'Server error - while fetching master key ..' it means >>>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>>> server work on the replica? What is in its error log >>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> >>>>>> >>>>> >>>> >>> -- >>> / 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 > From mbasti at redhat.com Tue Nov 10 15:00:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 16:00:13 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> Message-ID: <5642067D.4050405@redhat.com> On 10.11.2015 15:53, Gronde, Christopher (Contractor) wrote: > Ran into an error trying to set that > > # ldapmodify -a -D "cn=directory manager" -W > Enter LDAP Password: > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > nsslapd-acesslog-level: 260 it is nsslapd-accesslog-level with 2 'c' in access Martin > > modifying entry "cn=config" > ldap_modify: Server is unwilling to perform (53) > additional info: Unknown attribute nsslapd-acesslog-level will be ignored > > [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W > Enter LDAP Password: > ldap_bind: Inappropriate authentication (48) > > -----Original Message----- > From: Ludwig Krispenz [mailto:lkrispen at redhat.com] > Sent: Tuesday, November 10, 2015 9:48 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > > On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >> How do I change that log setting? Is that done in LDAP? Using ldapmodify? > yes, > ldapmodify ... > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > nsslapd-acesslog-level: 260 >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz >> Sent: Tuesday, November 10, 2015 9:03 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> Where can I verify or change the credentials it is trying to use? >>>> Is it my LDAP password? >>> No, according to your logs, it is your LDAP master trying to >>> replicate (push changes) to your LDAP replica: >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >> Set nsslapd-acesslog-level: 260 >> >> and then look what internal searches are done during the gssapi >> authentication >>> If that is true, it would be ldap/ Kerberos principal talking >>> to ldap/ Kerberos principal. If that fails, it means master >>> and replica KDCs have different understanding of both ldap/ >>> and ldap/ keys which most likely means keys were rotated on >>> master and weren't propagated to replica. >>> >>> How to solve it? One possibility is to set master's hostname as KDC >>> address in krb5.conf on replica, forcing LDAP server on replica to >>> use master's KDC. I'm absolutely not sure this will actually work but >>> at least it allows to see if we are indeed dealing with inconsistent >>> state of service principals' keys. >>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> When I tried to start the service again I got no response from tail >>>>> of the log, but this is a repeating entry I see in the access log >>>>> >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>> 127.0.0.1 to 127.0.0.1 >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>> nentries=0 etime=0 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>> >>>>> Does anyone know what err=14 or err=49 are? >>>> err=14 means SASL bind in progress -- i.e. multi-round processing is >>>> ongoing. This is normal for SASL GSSAPI. >>>> >>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>> It may also mean that LDAP server side was unable to process >>>> Kerberos negotiation due to not having a current Kerberos ticket for >>>> own service >>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>> KDC is down. >>>> >>>>> -----Original Message----- >>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>> To: Gronde, Christopher (Contractor) >>>>> ; Alexander Bokovoy >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> Gronde, Christopher (Contractor) wrote: >>>>>> Nothing bad came back and there is definitely data in the tree. >>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>> 389-ds access log (buffered) to: >>>>> >>>>> 1. See if it is binding at all >>>>> 2. See what the search is and what, if any, results were returned >>>>> >>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>> >>>>> rob >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>> what the error log shows >>>>>>> >>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>> operation threads >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>>>> internal subsystems and plugins >>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>>> stop >>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>> B2015.247.1737 starting up >>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>> Ok, that's good. >>>>>> >>>>>> I'd do something like this to see what is in the db (substitute >>>>>> example.com with your domain): >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>> cn=kerberos,dc=example,dc=com >>>>>> >>>>>> (don't post the output as it would include the kerberos master key). >>>>>> >>>>>> If that returns nothing that's bad. >>>>>> >>>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>>> you do >>>>>> have: >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>> >>>>>> I picked groups because usually groups << users in numbers. This >>>>>> is just to see if you have data in the tree. >>>>>> >>>>>> Let us know if either or both turns up nothing. >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> Hello all! >>>>>>>> >>>>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>>>> going on for sometime, I have all my certs figured out but the >>>>>>>> krb5kdc service will not start. >>>>>>>> >>>>>>>> # service krb5kdc start >>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>> >>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> >>>>>>>> I found this article online: >>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>> >>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>>> command >>>>>>>> listed: >>>>>>>> >>>>>>>> # kdb5_util stash >>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>> >>>>>>>> No further information found on the proceeding error above for >>>>>>>> the kdb5_util command. >>>>>>>> >>>>>>>> Any thoughts? >>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>> >>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>> anything else do not apply here at all. >>>>>>> >>>>>>> If you see 'Server error - while fetching master key ..' it means >>>>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>>>> server work on the replica? What is in its error log >>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>> >>>> -- >>>> / 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 >> > > From lkrispen at redhat.com Tue Nov 10 15:04:34 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 16:04:34 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> Message-ID: <56420782.2030408@redhat.com> it was a typo, try nsslapd-accesslog-level On 11/10/2015 03:53 PM, Gronde, Christopher (Contractor) wrote: > Ran into an error trying to set that > > # ldapmodify -a -D "cn=directory manager" -W > Enter LDAP Password: > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > : 260 > > modifying entry "cn=config" > ldap_modify: Server is unwilling to perform (53) > additional info: Unknown attribute nsslapd-acesslog-level will be ignored > > [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W > Enter LDAP Password: > ldap_bind: Inappropriate authentication (48) > > -----Original Message----- > From: Ludwig Krispenz [mailto:lkrispen at redhat.com] > Sent: Tuesday, November 10, 2015 9:48 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > > On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >> How do I change that log setting? Is that done in LDAP? Using ldapmodify? > yes, > ldapmodify ... > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > nsslapd-acesslog-level: 260 >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz >> Sent: Tuesday, November 10, 2015 9:03 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> Where can I verify or change the credentials it is trying to use? >>>> Is it my LDAP password? >>> No, according to your logs, it is your LDAP master trying to >>> replicate (push changes) to your LDAP replica: >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >> Set nsslapd-acesslog-level: 260 >> >> and then look what internal searches are done during the gssapi >> authentication >>> If that is true, it would be ldap/ Kerberos principal talking >>> to ldap/ Kerberos principal. If that fails, it means master >>> and replica KDCs have different understanding of both ldap/ >>> and ldap/ keys which most likely means keys were rotated on >>> master and weren't propagated to replica. >>> >>> How to solve it? One possibility is to set master's hostname as KDC >>> address in krb5.conf on replica, forcing LDAP server on replica to >>> use master's KDC. I'm absolutely not sure this will actually work but >>> at least it allows to see if we are indeed dealing with inconsistent >>> state of service principals' keys. >>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> When I tried to start the service again I got no response from tail >>>>> of the log, but this is a repeating entry I see in the access log >>>>> >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>> 127.0.0.1 to 127.0.0.1 >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>> nentries=0 etime=0 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>> >>>>> Does anyone know what err=14 or err=49 are? >>>> err=14 means SASL bind in progress -- i.e. multi-round processing is >>>> ongoing. This is normal for SASL GSSAPI. >>>> >>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>> It may also mean that LDAP server side was unable to process >>>> Kerberos negotiation due to not having a current Kerberos ticket for >>>> own service >>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>> KDC is down. >>>> >>>>> -----Original Message----- >>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>> To: Gronde, Christopher (Contractor) >>>>> ; Alexander Bokovoy >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> Gronde, Christopher (Contractor) wrote: >>>>>> Nothing bad came back and there is definitely data in the tree. >>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>> 389-ds access log (buffered) to: >>>>> >>>>> 1. See if it is binding at all >>>>> 2. See what the search is and what, if any, results were returned >>>>> >>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>> >>>>> rob >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>> what the error log shows >>>>>>> >>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>> operation threads >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down >>>>>>> internal subsystems and plugins >>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>>> stop >>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>> B2015.247.1737 starting up >>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>> Ok, that's good. >>>>>> >>>>>> I'd do something like this to see what is in the db (substitute >>>>>> example.com with your domain): >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>> cn=kerberos,dc=example,dc=com >>>>>> >>>>>> (don't post the output as it would include the kerberos master key). >>>>>> >>>>>> If that returns nothing that's bad. >>>>>> >>>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>>> you do >>>>>> have: >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>> >>>>>> I picked groups because usually groups << users in numbers. This >>>>>> is just to see if you have data in the tree. >>>>>> >>>>>> Let us know if either or both turns up nothing. >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> Hello all! >>>>>>>> >>>>>>>> On my replica IPA server after fixing a cert issue that had been >>>>>>>> going on for sometime, I have all my certs figured out but the >>>>>>>> krb5kdc service will not start. >>>>>>>> >>>>>>>> # service krb5kdc start >>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>> >>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> >>>>>>>> I found this article online: >>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>> >>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>>> command >>>>>>>> listed: >>>>>>>> >>>>>>>> # kdb5_util stash >>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>> >>>>>>>> No further information found on the proceeding error above for >>>>>>>> the kdb5_util command. >>>>>>>> >>>>>>>> Any thoughts? >>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>> >>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>> anything else do not apply here at all. >>>>>>> >>>>>>> If you see 'Server error - while fetching master key ..' it means >>>>>>> KDC LDAP driver was unable to contact LDAP server. Does LDAP >>>>>>> server work on the replica? What is in its error log >>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>> >>>> -- >>>> / 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 >> > From oliver at doerr-privat.de Tue Nov 10 15:13:18 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Tue, 10 Nov 2015 16:13:18 +0100 Subject: [Freeipa-users] First tests against the REST/JSON API In-Reply-To: <56420501.2060809@doerr-privat.de> References: <5640DEE0.20107@doerr-privat.de> <20151110081438.GP1147@redhat.com> <56420501.2060809@doerr-privat.de> Message-ID: <5642098E.6050406@doerr-privat.de> Hello, just because I could answer my 2nd problem by myself. The truncated does not come from user_find API. It came from the perl JSON module, this is using this to write boolean variables. There is a special handling for boolean values inside this module which I have to implement. Regards Oliver Am 10.11.2015 um 15:53 schrieb Oliver D?rr: > Hi Alexander, > > sorry for responding you privately. This was not my intention; I just > recognized that my mail program has two reply buttons (replay and > reply to mailing list). > > I've played a bit around with your code and implemented a small Perl > module and a test script. They both work in my environment, however > I'm still not happy with them. > > What I don't like is... > 1st, I need to provide my client version > 2nd, I get the message 'truncated' => bless( do{\(my $o = 0)}, > 'JSON::PP::Boolean' ) from the user_find API > 3rd, I do not know what the id is used for and so I'm unsure if I > could automatically handle it in my Perl module > > However they should be a help for others who wants use Perl-script to > access IPA-API. > > Anyway thanks for your help. This was what I need to get on the track. > > Oliver > > Am 10.11.2015 um 09:14 schrieb Alexander Bokovoy: >> On Mon, 09 Nov 2015, Natxo Asenjo wrote: >>> hi, >>> >>> On Mon, Nov 9, 2015 at 6:58 PM, Oliver D?rr >>> wrote: >>> >>>> Hi, >>>> >>>> I'm completly new to this list and the product behind it. I'm >>>> trying to >>>> use perl to get a list from my IPA installation of all users that >>>> are on >>>> the server. >>>> >>> >>> unfortunately I cannot help you right now, but have you taken a look at >>> this blog post: >>> >>> https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ >>> >>> >>> It could give you some pointers. >>> >>> Share your code if you get it to work :-) >> The code in my response (see other mail) works fine, Oliver contacted me >> privately. >> >> Oliver, please respond to the list. :) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Gronde at fincen.gov Tue Nov 10 15:18:53 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 15:18:53 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56420782.2030408@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> Thank you! I should have caught that... I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping tree,cn=config" scope=1 filter="(&(objectclass=nsMappingTree)(!(nsslapd-parent-suffix=*)))" attrs=ALL [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping tree,cn=config" scope=1 filter="(&(objectclass=nsMappingTree)(|(nsslapd-parent-suffix="dc=itmodev,dc=gov")(nsslapd-parent-suffix=dc=itmodev,dc=gov)))" attrs=ALL [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="oid=2.16.840.1.113730.3.4.9,cn=features,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="oid=2.16.840.1.113730.3.5.7,cn=features,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=options,cn=features,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=encryption,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=monitor" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=snmp,cn=monitor" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=counters,cn=monitor" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=sasl,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=mapping,cn=sasl,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=SNMP,cn=config" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory Team,cn=monitor" [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid generator,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" scope=2 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=15 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=upgradedb,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=syntax validate,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=schema reload task,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=restore,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=index,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=import,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked attributes,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=export,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=cleanallruv,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=backup,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember rebuild membership,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember map updates,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember export updates,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=abort cleanallruv,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Binary Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Bit String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Bitwise Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Boolean Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Case Exact String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Case Ignore String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Country String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Delivery Method Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Distinguished Name Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Enhanced Guide Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Facsimile Telephone Number Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Fax Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Generalized Time Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Guide Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Integer Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Internationalization Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=JPEG Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Name And Optional UID Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Numeric String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Octet String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=OID Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Postal Address Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Printable String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Space Insensitive String Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Telephone Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Teletex Terminal Identifier Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Telex Number Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=URI Syntax,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=CLEAR,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=CRYPT,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=MD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=NS-MTA-MD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SMD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Account Policy Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=attribute uniqueness,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=chaining database,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ldbm database,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvsearch)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvindex)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Linked Attributes,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=fixup linked attributes,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Managed Entries,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=MemberOf Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=PAM Pass Through Auth,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Pass Through Authentication,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=referential integrity postoperation,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Retro Changelog Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Schema Reload,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=schema reload task,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=State Change Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Syntax Validation Task,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=syntax validate,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=USN,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Views,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="objectclass=*" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=7-bit check,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ACL Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config" scope=0 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=ACL Plugin,cn=plugins,cn=config" scope=0 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ACL preoperation,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Auto Membership Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember rebuild membership,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember export updates,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember map updates,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Class of Service,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=deref,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=HTTP Client,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Multimaster Replication Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=cleanallruv,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=abort cleanallruv,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Roles Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Legacy Replication Plugin,cn=plugins,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=import,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=export,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=backup,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=restore,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=index,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=upgradedb,cn=tasks,cn=config" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="dc=itmodev,dc=gov" [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=16 tag=48 nentries=0 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=1 filter="(objectclass=nsSaslMapping)" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=6 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Name Only,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Full Principal,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:10:11:43 -0500] conn=1 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:11:43 -0500] conn=1 op=0 UNBIND [10/Nov/2015:10:11:43 -0500] conn=1 op=0 fd=64 closed - U1 [10/Nov/2015:10:11:45 -0500] conn=2 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:11:45 -0500] conn=2 op=0 UNBIND [10/Nov/2015:10:11:45 -0500] conn=2 op=0 fd=64 closed - U1 [10/Nov/2015:10:11:53 -0500] conn=3 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:11:53 -0500] conn=3 op=0 UNBIND [10/Nov/2015:10:11:53 -0500] conn=3 op=0 fd=64 closed - U1 [10/Nov/2015:10:11:55 -0500] conn=4 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:11:55 -0500] conn=4 op=0 UNBIND [10/Nov/2015:10:11:55 -0500] conn=4 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 172.16.100.208 to 172.16.100.161 [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 [10/Nov/2015:10:12:13 -0500] conn=6 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:13 -0500] conn=6 op=0 UNBIND [10/Nov/2015:10:12:13 -0500] conn=6 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:15 -0500] conn=7 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:15 -0500] conn=7 op=0 UNBIND [10/Nov/2015:10:12:15 -0500] conn=7 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:24 -0500] conn=8 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:24 -0500] conn=8 op=0 UNBIND [10/Nov/2015:10:12:24 -0500] conn=8 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:25 -0500] conn=9 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:25 -0500] conn=9 op=0 UNBIND [10/Nov/2015:10:12:25 -0500] conn=9 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:43 -0500] conn=10 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:43 -0500] conn=10 op=0 UNBIND [10/Nov/2015:10:12:43 -0500] conn=10 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:45 -0500] conn=11 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:45 -0500] conn=11 op=0 UNBIND [10/Nov/2015:10:12:45 -0500] conn=11 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:54 -0500] conn=12 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:54 -0500] conn=12 op=0 UNBIND [10/Nov/2015:10:12:54 -0500] conn=12 op=0 fd=64 closed - U1 [10/Nov/2015:10:12:55 -0500] conn=13 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:12:55 -0500] conn=13 op=0 UNBIND [10/Nov/2015:10:12:55 -0500] conn=13 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:14 -0500] conn=14 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:14 -0500] conn=14 op=0 UNBIND [10/Nov/2015:10:13:14 -0500] conn=14 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:16 -0500] conn=15 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:16 -0500] conn=15 op=0 UNBIND [10/Nov/2015:10:13:16 -0500] conn=15 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:24 -0500] conn=16 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:24 -0500] conn=16 op=0 UNBIND [10/Nov/2015:10:13:24 -0500] conn=16 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:25 -0500] conn=17 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:25 -0500] conn=17 op=0 UNBIND [10/Nov/2015:10:13:25 -0500] conn=17 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:44 -0500] conn=18 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:44 -0500] conn=18 op=0 UNBIND [10/Nov/2015:10:13:44 -0500] conn=18 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:46 -0500] conn=19 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:46 -0500] conn=19 op=0 UNBIND [10/Nov/2015:10:13:46 -0500] conn=19 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:54 -0500] conn=20 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:54 -0500] conn=20 op=0 UNBIND [10/Nov/2015:10:13:54 -0500] conn=20 op=0 fd=64 closed - U1 [10/Nov/2015:10:13:56 -0500] conn=21 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:13:56 -0500] conn=21 op=0 UNBIND [10/Nov/2015:10:13:56 -0500] conn=21 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:14 -0500] conn=22 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:14 -0500] conn=22 op=0 UNBIND [10/Nov/2015:10:14:14 -0500] conn=22 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:16 -0500] conn=23 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:16 -0500] conn=23 op=0 UNBIND [10/Nov/2015:10:14:16 -0500] conn=23 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:25 -0500] conn=24 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:25 -0500] conn=24 op=0 UNBIND [10/Nov/2015:10:14:25 -0500] conn=24 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:26 -0500] conn=25 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:26 -0500] conn=25 op=0 UNBIND [10/Nov/2015:10:14:26 -0500] conn=25 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:45 -0500] conn=26 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:45 -0500] conn=26 op=0 UNBIND [10/Nov/2015:10:14:45 -0500] conn=26 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:46 -0500] conn=27 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:46 -0500] conn=27 op=0 UNBIND [10/Nov/2015:10:14:46 -0500] conn=27 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:55 -0500] conn=28 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:55 -0500] conn=28 op=0 UNBIND [10/Nov/2015:10:14:55 -0500] conn=28 op=0 fd=64 closed - U1 [10/Nov/2015:10:14:56 -0500] conn=29 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:14:56 -0500] conn=29 op=0 UNBIND [10/Nov/2015:10:14:56 -0500] conn=29 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:15 -0500] conn=30 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:15 -0500] conn=30 op=0 UNBIND [10/Nov/2015:10:15:15 -0500] conn=30 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:17 -0500] conn=31 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:17 -0500] conn=31 op=0 UNBIND [10/Nov/2015:10:15:17 -0500] conn=31 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:25 -0500] conn=32 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:25 -0500] conn=32 op=0 UNBIND [10/Nov/2015:10:15:25 -0500] conn=32 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:26 -0500] conn=33 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:26 -0500] conn=33 op=0 UNBIND [10/Nov/2015:10:15:26 -0500] conn=33 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:45 -0500] conn=34 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:45 -0500] conn=34 op=0 UNBIND [10/Nov/2015:10:15:45 -0500] conn=34 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:47 -0500] conn=35 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:47 -0500] conn=35 op=0 UNBIND [10/Nov/2015:10:15:47 -0500] conn=35 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:55 -0500] conn=36 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:55 -0500] conn=36 op=0 UNBIND [10/Nov/2015:10:15:55 -0500] conn=36 op=0 fd=64 closed - U1 [10/Nov/2015:10:15:57 -0500] conn=37 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:15:57 -0500] conn=37 op=0 UNBIND [10/Nov/2015:10:15:57 -0500] conn=37 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:15 -0500] conn=38 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:15 -0500] conn=38 op=0 UNBIND [10/Nov/2015:10:16:15 -0500] conn=38 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:17 -0500] conn=39 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:17 -0500] conn=39 op=0 UNBIND [10/Nov/2015:10:16:17 -0500] conn=39 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:26 -0500] conn=40 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:26 -0500] conn=40 op=0 UNBIND [10/Nov/2015:10:16:26 -0500] conn=40 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:27 -0500] conn=41 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:27 -0500] conn=41 op=0 UNBIND [10/Nov/2015:10:16:27 -0500] conn=41 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:46 -0500] conn=42 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:46 -0500] conn=42 op=0 UNBIND [10/Nov/2015:10:16:46 -0500] conn=42 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:47 -0500] conn=43 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:47 -0500] conn=43 op=0 UNBIND [10/Nov/2015:10:16:47 -0500] conn=43 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:56 -0500] conn=44 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:56 -0500] conn=44 op=0 UNBIND [10/Nov/2015:10:16:56 -0500] conn=44 op=0 fd=64 closed - U1 [10/Nov/2015:10:16:57 -0500] conn=45 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 [10/Nov/2015:10:16:57 -0500] conn=45 op=0 UNBIND [10/Nov/2015:10:16:57 -0500] conn=45 op=0 fd=64 closed - U1 -----Original Message----- From: Ludwig Krispenz [mailto:lkrispen at redhat.com] Sent: Tuesday, November 10, 2015 10:05 AM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) it was a typo, try nsslapd-accesslog-level On 11/10/2015 03:53 PM, Gronde, Christopher (Contractor) wrote: > Ran into an error trying to set that > > # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > : 260 > > modifying entry "cn=config" > ldap_modify: Server is unwilling to perform (53) > additional info: Unknown attribute nsslapd-acesslog-level > will be ignored > > [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP > Password: > ldap_bind: Inappropriate authentication (48) > > -----Original Message----- > From: Ludwig Krispenz [mailto:lkrispen at redhat.com] > Sent: Tuesday, November 10, 2015 9:48 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > > On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >> How do I change that log setting? Is that done in LDAP? Using ldapmodify? > yes, > ldapmodify ... > dn: cn=config > changetype: modify > replace: nsslapd-acesslog-level > nsslapd-acesslog-level: 260 >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >> Krispenz >> Sent: Tuesday, November 10, 2015 9:03 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>> Where can I verify or change the credentials it is trying to use? >>>> Is it my LDAP password? >>> No, according to your logs, it is your LDAP master trying to >>> replicate (push changes) to your LDAP replica: >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >> Set nsslapd-acesslog-level: 260 >> >> and then look what internal searches are done during the gssapi >> authentication >>> If that is true, it would be ldap/ Kerberos principal >>> talking to ldap/ Kerberos principal. If that fails, it >>> means master and replica KDCs have different understanding of both >>> ldap/ and ldap/ keys which most likely means keys >>> were rotated on master and weren't propagated to replica. >>> >>> How to solve it? One possibility is to set master's hostname as KDC >>> address in krb5.conf on replica, forcing LDAP server on replica to >>> use master's KDC. I'm absolutely not sure this will actually work >>> but at least it allows to see if we are indeed dealing with >>> inconsistent state of service principals' keys. >>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> When I tried to start the service again I got no response from >>>>> tail of the log, but this is a repeating entry I see in the access >>>>> log >>>>> >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>> 127.0.0.1 to 127.0.0.1 >>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>> to >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>> nentries=0 etime=0 >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>> >>>>> Does anyone know what err=14 or err=49 are? >>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>> is ongoing. This is normal for SASL GSSAPI. >>>> >>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>> It may also mean that LDAP server side was unable to process >>>> Kerberos negotiation due to not having a current Kerberos ticket >>>> for own service >>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>> KDC is down. >>>> >>>>> -----Original Message----- >>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>> To: Gronde, Christopher (Contractor) >>>>> ; Alexander Bokovoy >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> Gronde, Christopher (Contractor) wrote: >>>>>> Nothing bad came back and there is definitely data in the tree. >>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>> 389-ds access log (buffered) to: >>>>> >>>>> 1. See if it is binding at all >>>>> 2. See what the search is and what, if any, results were returned >>>>> >>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>> >>>>> rob >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>> what the error log shows >>>>>>> >>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>> operation threads >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>> down internal subsystems and plugins >>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>>> stop >>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>> B2015.247.1737 starting up >>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>> Ok, that's good. >>>>>> >>>>>> I'd do something like this to see what is in the db (substitute >>>>>> example.com with your domain): >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>> cn=kerberos,dc=example,dc=com >>>>>> >>>>>> (don't post the output as it would include the kerberos master key). >>>>>> >>>>>> If that returns nothing that's bad. >>>>>> >>>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>>> you do >>>>>> have: >>>>>> >>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>> >>>>>> I picked groups because usually groups << users in numbers. This >>>>>> is just to see if you have data in the tree. >>>>>> >>>>>> Let us know if either or both turns up nothing. >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> Hello all! >>>>>>>> >>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>> been going on for sometime, I have all my certs figured out but >>>>>>>> the krb5kdc service will not start. >>>>>>>> >>>>>>>> # service krb5kdc start >>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>> >>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>> ITMODEV.GOV >>>>>>>> >>>>>>>> I found this article online: >>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>> >>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>>> command >>>>>>>> listed: >>>>>>>> >>>>>>>> # kdb5_util stash >>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>> >>>>>>>> No further information found on the proceeding error above for >>>>>>>> the kdb5_util command. >>>>>>>> >>>>>>>> Any thoughts? >>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>> >>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>> anything else do not apply here at all. >>>>>>> >>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>> LDAP server work on the replica? What is in its error log >>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>> >>>> -- >>>> / 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 >> > From seike at outlook.com Tue Nov 10 15:24:42 2015 From: seike at outlook.com (Seike neg) Date: Tue, 10 Nov 2015 16:24:42 +0100 Subject: [Freeipa-users] Sync with SUN DS 5.2 Message-ID: Hello, Is there a way to import users and password from SUN DS automatically (script, sync, etc...). I have a SUN DS LDAP in the office and I want to do a read only sync from him to a brand new freeipa server. The freeipa server is suppose to act as a kerberos, ldap slave and ntp server. From rcritten at redhat.com Tue Nov 10 15:39:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2015 10:39:10 -0500 Subject: [Freeipa-users] Sync with SUN DS 5.2 In-Reply-To: References: Message-ID: <56420F9E.1030903@redhat.com> Seike neg wrote: > Hello, > Is there a way to import users and password from SUN DS automatically (script, sync, etc...). > I have a SUN DS LDAP in the office and I want to do a read only sync from him to a brand new freeipa server. > The freeipa server is suppose to act as a kerberos, ldap slave and ntp server. > > It's a little unclear what you want to do. Do you want a periodic sync or a one-time migration? You can use ipa migrate-ds to migrate over LDAP. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html rob From natxo.asenjo at gmail.com Tue Nov 10 15:17:12 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 10 Nov 2015 16:17:12 +0100 Subject: [Freeipa-users] crl url redirecting to https Message-ID: hi, I just noticed some stuff was not functioning properly and it's because the crl url is being redirected to https (centos 6.7). $ curl http://kdc01.unix.domain.tld/ipa/crl/ 301 Moved Permanently

Moved Permanently

The document has moved here.

Apache/2.2.15 (CentOS) Server at kdc01.unix.domain.tld Port 80
This is ipa-rewrite.conf, it should not be happening, but it does: $ cat ipa-rewrite.conf # VERSION 3 - DO NOT REMOVE THIS LINE RewriteEngine on # By default forward all requests to /ipa. If you don't want IPA # to be the default on your web server comment this line out. RewriteRule ^/$ https://kdc01.unix.iriszorg.nl/ipa/ui [L,NC,R=301] # Redirect to the fully-qualified hostname. Not redirecting to secure # port so configuration files can be retrieved without requiring SSL. RewriteCond %{HTTP_HOST} !^kdc01.unix.iriszorg.nl$ [NC] RewriteRule ^/ipa/(.*) http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301] # Redirect to the secure port if not displaying an error or retrieving # configuration. RewriteCond %{SERVER_PORT} !^443$ RewriteCond %{REQUEST_URI} !^/ipa/(errors|config) RewriteRule ^/ipa/(.*) https://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301,NC] Any ideas on how to fix this? Thanks! -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 10 15:44:13 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 08:44:13 -0700 Subject: [Freeipa-users] Sync with SUN DS 5.2 In-Reply-To: <56420F9E.1030903@redhat.com> References: <56420F9E.1030903@redhat.com> Message-ID: <564210CD.4000307@redhat.com> On 11/10/2015 08:39 AM, Rob Crittenden wrote: > Seike neg wrote: >> Hello, >> Is there a way to import users and password from SUN DS automatically (script, sync, etc...). >> I have a SUN DS LDAP in the office and I want to do a read only sync from him to a brand new freeipa server. >> The freeipa server is suppose to act as a kerberos, ldap slave and ntp server. >> >> > It's a little unclear what you want to do. Do you want a periodic sync > or a one-time migration? > > You can use ipa migrate-ds to migrate over LDAP. See > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html You can also configure SunDS 5.2 to replicate to IPA, and vice versa. > > rob > From lkrispen at redhat.com Tue Nov 10 16:06:42 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 17:06:42 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> Message-ID: <56421612.2070400@redhat.com> so this search conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" doesn't return an entry. but I think it look for something like "krbprincipal=ldap/...." what entries do you have below cn=mapping,cn=sasl,cn=config On 11/10/2015 04:18 PM, Gronde, Christopher (Contractor) wrote: > Thank you! I should have caught that... > > I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... > > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping tree,cn=config" scope=1 filter="(&(objectclass=nsMappingTree)(!(nsslapd-parent-suffix=*)))" attrs=ALL > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping tree,cn=config" scope=1 filter="(&(objectclass=nsMappingTree)(|(nsslapd-parent-suffix="dc=itmodev,dc=gov")(nsslapd-parent-suffix=dc=itmodev,dc=gov)))" attrs=ALL > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="oid=2.16.840.1.113730.3.4.9,cn=features,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="oid=2.16.840.1.113730.3.5.7,cn=features,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=options,cn=features,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=encryption,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=monitor" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=snmp,cn=monitor" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=counters,cn=monitor" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=sasl,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=mapping,cn=sasl,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=SNMP,cn=config" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory Team,cn=monitor" > [10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid generator,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" scope=2 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=15 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=upgradedb,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=syntax validate,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=schema reload task,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=restore,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=index,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=import,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked attributes,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=export,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=backup,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember rebuild membership,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember map updates,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=automember export updates,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=abort cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Binary Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Bit String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Bitwise Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Boolean Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Case Exact String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Case Ignore String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Country String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Delivery Method Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Distinguished Name Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Enhanced Guide Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Facsimile Telephone Number Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Fax Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Generalized Time Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Guide Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Integer Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Internationalization Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=JPEG Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Name And Optional UID Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Numeric String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Octet String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=OID Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Postal Address Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Printable String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Space Insensitive String Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Telephone Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Teletex Terminal Identifier Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Telex Number Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=URI Syntax,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=CLEAR,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=CRYPT,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=MD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=NS-MTA-MD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SMD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Account Policy Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=attribute uniqueness,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=chaining database,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ldbm database,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvsearch)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvindex)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Linked Attributes,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=fixup linked attributes,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Managed Entries,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=MemberOf Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=PAM Pass Through Auth,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Pass Through Authentication,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=referential integrity postoperation,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Retro Changelog Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Schema Reload,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=schema reload task,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=State Change Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Syntax Validation Task,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=syntax validate,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=USN,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Views,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="objectclass=*" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=7-bit check,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ACL Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config" scope=0 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=ACL Plugin,cn=plugins,cn=config" scope=0 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=ACL preoperation,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Auto Membership Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember rebuild membership,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember export updates,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=automember map updates,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Class of Service,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=deref,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=HTTP Client,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Multimaster Replication Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=abort cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Roles Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=Legacy Replication Plugin,cn=plugins,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=import,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=export,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=backup,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=restore,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=index,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 ADD dn="cn=upgradedb,cn=tasks,cn=config" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="dc=itmodev,dc=gov" > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=16 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=1 filter="(objectclass=nsSaslMapping)" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=6 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Name Only,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=Full Principal,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:10:11:43 -0500] conn=1 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:11:43 -0500] conn=1 op=0 UNBIND > [10/Nov/2015:10:11:43 -0500] conn=1 op=0 fd=64 closed - U1 > [10/Nov/2015:10:11:45 -0500] conn=2 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:11:45 -0500] conn=2 op=0 UNBIND > [10/Nov/2015:10:11:45 -0500] conn=2 op=0 fd=64 closed - U1 > [10/Nov/2015:10:11:53 -0500] conn=3 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:11:53 -0500] conn=3 op=0 UNBIND > [10/Nov/2015:10:11:53 -0500] conn=3 op=0 fd=64 closed - U1 > [10/Nov/2015:10:11:55 -0500] conn=4 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:11:55 -0500] conn=4 op=0 UNBIND > [10/Nov/2015:10:11:55 -0500] conn=4 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 172.16.100.208 to 172.16.100.161 > [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 > [10/Nov/2015:10:12:13 -0500] conn=6 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:13 -0500] conn=6 op=0 UNBIND > [10/Nov/2015:10:12:13 -0500] conn=6 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:15 -0500] conn=7 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:15 -0500] conn=7 op=0 UNBIND > [10/Nov/2015:10:12:15 -0500] conn=7 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:24 -0500] conn=8 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:24 -0500] conn=8 op=0 UNBIND > [10/Nov/2015:10:12:24 -0500] conn=8 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:25 -0500] conn=9 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:25 -0500] conn=9 op=0 UNBIND > [10/Nov/2015:10:12:25 -0500] conn=9 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:43 -0500] conn=10 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:43 -0500] conn=10 op=0 UNBIND > [10/Nov/2015:10:12:43 -0500] conn=10 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:45 -0500] conn=11 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:45 -0500] conn=11 op=0 UNBIND > [10/Nov/2015:10:12:45 -0500] conn=11 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:54 -0500] conn=12 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:54 -0500] conn=12 op=0 UNBIND > [10/Nov/2015:10:12:54 -0500] conn=12 op=0 fd=64 closed - U1 > [10/Nov/2015:10:12:55 -0500] conn=13 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:12:55 -0500] conn=13 op=0 UNBIND > [10/Nov/2015:10:12:55 -0500] conn=13 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:14 -0500] conn=14 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:14 -0500] conn=14 op=0 UNBIND > [10/Nov/2015:10:13:14 -0500] conn=14 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:16 -0500] conn=15 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:16 -0500] conn=15 op=0 UNBIND > [10/Nov/2015:10:13:16 -0500] conn=15 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:24 -0500] conn=16 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:24 -0500] conn=16 op=0 UNBIND > [10/Nov/2015:10:13:24 -0500] conn=16 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:25 -0500] conn=17 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:25 -0500] conn=17 op=0 UNBIND > [10/Nov/2015:10:13:25 -0500] conn=17 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:44 -0500] conn=18 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:44 -0500] conn=18 op=0 UNBIND > [10/Nov/2015:10:13:44 -0500] conn=18 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:46 -0500] conn=19 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:46 -0500] conn=19 op=0 UNBIND > [10/Nov/2015:10:13:46 -0500] conn=19 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:54 -0500] conn=20 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:54 -0500] conn=20 op=0 UNBIND > [10/Nov/2015:10:13:54 -0500] conn=20 op=0 fd=64 closed - U1 > [10/Nov/2015:10:13:56 -0500] conn=21 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:13:56 -0500] conn=21 op=0 UNBIND > [10/Nov/2015:10:13:56 -0500] conn=21 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:14 -0500] conn=22 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:14 -0500] conn=22 op=0 UNBIND > [10/Nov/2015:10:14:14 -0500] conn=22 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:16 -0500] conn=23 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:16 -0500] conn=23 op=0 UNBIND > [10/Nov/2015:10:14:16 -0500] conn=23 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:25 -0500] conn=24 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:25 -0500] conn=24 op=0 UNBIND > [10/Nov/2015:10:14:25 -0500] conn=24 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:26 -0500] conn=25 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:26 -0500] conn=25 op=0 UNBIND > [10/Nov/2015:10:14:26 -0500] conn=25 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:45 -0500] conn=26 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:45 -0500] conn=26 op=0 UNBIND > [10/Nov/2015:10:14:45 -0500] conn=26 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:46 -0500] conn=27 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:46 -0500] conn=27 op=0 UNBIND > [10/Nov/2015:10:14:46 -0500] conn=27 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:55 -0500] conn=28 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:55 -0500] conn=28 op=0 UNBIND > [10/Nov/2015:10:14:55 -0500] conn=28 op=0 fd=64 closed - U1 > [10/Nov/2015:10:14:56 -0500] conn=29 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:14:56 -0500] conn=29 op=0 UNBIND > [10/Nov/2015:10:14:56 -0500] conn=29 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:15 -0500] conn=30 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:15 -0500] conn=30 op=0 UNBIND > [10/Nov/2015:10:15:15 -0500] conn=30 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:17 -0500] conn=31 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:17 -0500] conn=31 op=0 UNBIND > [10/Nov/2015:10:15:17 -0500] conn=31 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:25 -0500] conn=32 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:25 -0500] conn=32 op=0 UNBIND > [10/Nov/2015:10:15:25 -0500] conn=32 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:26 -0500] conn=33 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:26 -0500] conn=33 op=0 UNBIND > [10/Nov/2015:10:15:26 -0500] conn=33 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:45 -0500] conn=34 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:45 -0500] conn=34 op=0 UNBIND > [10/Nov/2015:10:15:45 -0500] conn=34 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:47 -0500] conn=35 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:47 -0500] conn=35 op=0 UNBIND > [10/Nov/2015:10:15:47 -0500] conn=35 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:55 -0500] conn=36 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:55 -0500] conn=36 op=0 UNBIND > [10/Nov/2015:10:15:55 -0500] conn=36 op=0 fd=64 closed - U1 > [10/Nov/2015:10:15:57 -0500] conn=37 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:15:57 -0500] conn=37 op=0 UNBIND > [10/Nov/2015:10:15:57 -0500] conn=37 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:15 -0500] conn=38 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:15 -0500] conn=38 op=0 UNBIND > [10/Nov/2015:10:16:15 -0500] conn=38 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:17 -0500] conn=39 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:17 -0500] conn=39 op=0 UNBIND > [10/Nov/2015:10:16:17 -0500] conn=39 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:26 -0500] conn=40 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:26 -0500] conn=40 op=0 UNBIND > [10/Nov/2015:10:16:26 -0500] conn=40 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:27 -0500] conn=41 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:27 -0500] conn=41 op=0 UNBIND > [10/Nov/2015:10:16:27 -0500] conn=41 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:46 -0500] conn=42 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:46 -0500] conn=42 op=0 UNBIND > [10/Nov/2015:10:16:46 -0500] conn=42 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:47 -0500] conn=43 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:47 -0500] conn=43 op=0 UNBIND > [10/Nov/2015:10:16:47 -0500] conn=43 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:56 -0500] conn=44 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:56 -0500] conn=44 op=0 UNBIND > [10/Nov/2015:10:16:56 -0500] conn=44 op=0 fd=64 closed - U1 > [10/Nov/2015:10:16:57 -0500] conn=45 fd=64 slot=64 connection from 172.16.100.161 to 172.16.100.161 > [10/Nov/2015:10:16:57 -0500] conn=45 op=0 UNBIND > [10/Nov/2015:10:16:57 -0500] conn=45 op=0 fd=64 closed - U1 > > -----Original Message----- > From: Ludwig Krispenz [mailto:lkrispen at redhat.com] > Sent: Tuesday, November 10, 2015 10:05 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > it was a typo, try > > nsslapd-accesslog-level > > On 11/10/2015 03:53 PM, Gronde, Christopher (Contractor) wrote: >> Ran into an error trying to set that >> >> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> : 260 >> >> modifying entry "cn=config" >> ldap_modify: Server is unwilling to perform (53) >> additional info: Unknown attribute nsslapd-acesslog-level >> will be ignored >> >> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >> Password: >> ldap_bind: Inappropriate authentication (48) >> >> -----Original Message----- >> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >> Sent: Tuesday, November 10, 2015 9:48 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >> yes, >> ldapmodify ... >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> nsslapd-acesslog-level: 260 >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>> Krispenz >>> Sent: Tuesday, November 10, 2015 9:03 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> Where can I verify or change the credentials it is trying to use? >>>>> Is it my LDAP password? >>>> No, according to your logs, it is your LDAP master trying to >>>> replicate (push changes) to your LDAP replica: >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>> Set nsslapd-acesslog-level: 260 >>> >>> and then look what internal searches are done during the gssapi >>> authentication >>>> If that is true, it would be ldap/ Kerberos principal >>>> talking to ldap/ Kerberos principal. If that fails, it >>>> means master and replica KDCs have different understanding of both >>>> ldap/ and ldap/ keys which most likely means keys >>>> were rotated on master and weren't propagated to replica. >>>> >>>> How to solve it? One possibility is to set master's hostname as KDC >>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>> use master's KDC. I'm absolutely not sure this will actually work >>>> but at least it allows to see if we are indeed dealing with >>>> inconsistent state of service principals' keys. >>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> When I tried to start the service again I got no response from >>>>>> tail of the log, but this is a repeating entry I see in the access >>>>>> log >>>>>> >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>> 127.0.0.1 to 127.0.0.1 >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>> nentries=0 etime=0 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>> >>>>>> Does anyone know what err=14 or err=49 are? >>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>> is ongoing. This is normal for SASL GSSAPI. >>>>> >>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>> It may also mean that LDAP server side was unable to process >>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>> for own service >>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>> KDC is down. >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>> 389-ds access log (buffered) to: >>>>>> >>>>>> 1. See if it is binding at all >>>>>> 2. See what the search is and what, if any, results were returned >>>>>> >>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>> what the error log shows >>>>>>>> >>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>> operation threads >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>> down internal subsystems and plugins >>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>>>> stop >>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>> B2015.247.1737 starting up >>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>> Ok, that's good. >>>>>>> >>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>> example.com with your domain): >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>> cn=kerberos,dc=example,dc=com >>>>>>> >>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>> >>>>>>> If that returns nothing that's bad. >>>>>>> >>>>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>>>> you do >>>>>>> have: >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>> >>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>> is just to see if you have data in the tree. >>>>>>> >>>>>>> Let us know if either or both turns up nothing. >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Hello all! >>>>>>>>> >>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>> been going on for sometime, I have all my certs figured out but >>>>>>>>> the krb5kdc service will not start. >>>>>>>>> >>>>>>>>> # service krb5kdc start >>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>> >>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> >>>>>>>>> I found this article online: >>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>> >>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>>>> command >>>>>>>>> listed: >>>>>>>>> >>>>>>>>> # kdb5_util stash >>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>> >>>>>>>>> No further information found on the proceeding error above for >>>>>>>>> the kdb5_util command. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>> >>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>> anything else do not apply here at all. >>>>>>>> >>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>>> >>>>>>>> >>>>> -- >>>>> / 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 >>> > From rcritten at redhat.com Tue Nov 10 16:02:50 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2015 11:02:50 -0500 Subject: [Freeipa-users] crl url redirecting to https In-Reply-To: References: Message-ID: <5642152A.3030204@redhat.com> Natxo Asenjo wrote: > hi, > > I just noticed some stuff was not functioning properly and it's because > the crl url is being redirected to https (centos 6.7). > > > $ curl http://kdc01.unix.domain.tld/ipa/crl/ > > > 301 Moved Permanently > >

Moved Permanently

>

The document has moved href="https://kdc01.unix.domain.tld/ipa/crl/">here.

>
>
Apache/2.2.15 (CentOS) Server at kdc01.unix.domain.tld Port > 80
> > > This is ipa-rewrite.conf, it should not be happening, but it does: > > $ cat ipa-rewrite.conf > # VERSION 3 - DO NOT REMOVE THIS LINE > > RewriteEngine on > > # By default forward all requests to /ipa. If you don't want IPA > # to be the default on your web server comment this line out. > RewriteRule ^/$ https://kdc01.unix.iriszorg.nl/ipa/ui [L,NC,R=301] > > # Redirect to the fully-qualified hostname. Not redirecting to secure > # port so configuration files can be retrieved without requiring SSL. > RewriteCond %{HTTP_HOST} !^kdc01.unix.iriszorg.nl > $ [NC] > RewriteRule ^/ipa/(.*) http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301] > > # Redirect to the secure port if not displaying an error or retrieving > # configuration. > RewriteCond %{SERVER_PORT} !^443$ > RewriteCond %{REQUEST_URI} !^/ipa/(errors|config) > RewriteRule ^/ipa/(.*) https://kdc01.unix.iriszorg.nl/ipa/$1 > [L,R=301,NC] > > Any ideas on how to fix this? You should have a sections like these in /etc/httpd/conf.d/ipa.conf: SetHandler None ... # For CRL publishing Alias /ipa/crl "/var/lib/ipa/pki-ca/publish" SetHandler None AllowOverride None Options Indexes FollowSymLinks Satisfy Any Allow from all rob From rmeggins at redhat.com Tue Nov 10 16:04:13 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 09:04:13 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> Message-ID: <5642157D.30900@redhat.com> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: > Thank you! I should have caught that... > > I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 172.16.100.208 to 172.16.100.161 [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 This is the SASL bind. It thinks the principal in the Kerberos credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the code to look for something with uid=ldap/comipa01.itmodev.gov under dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 tag=48 nentries=0. nentries=0 means no entries matched the search criteria. You can do the search yourself with ldapsearch: ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' If you want to find out if there is some other ldap principal, do a search like this: ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> Ran into an error trying to set that >> >> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> : 260 >> >> modifying entry "cn=config" >> ldap_modify: Server is unwilling to perform (53) >> additional info: Unknown attribute nsslapd-acesslog-level >> will be ignored >> >> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >> Password: >> ldap_bind: Inappropriate authentication (48) >> >> -----Original Message----- >> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >> Sent: Tuesday, November 10, 2015 9:48 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >> yes, >> ldapmodify ... >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> nsslapd-acesslog-level: 260 >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>> Krispenz >>> Sent: Tuesday, November 10, 2015 9:03 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> Where can I verify or change the credentials it is trying to use? >>>>> Is it my LDAP password? >>>> No, according to your logs, it is your LDAP master trying to >>>> replicate (push changes) to your LDAP replica: >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>> Set nsslapd-acesslog-level: 260 >>> >>> and then look what internal searches are done during the gssapi >>> authentication >>>> If that is true, it would be ldap/ Kerberos principal >>>> talking to ldap/ Kerberos principal. If that fails, it >>>> means master and replica KDCs have different understanding of both >>>> ldap/ and ldap/ keys which most likely means keys >>>> were rotated on master and weren't propagated to replica. >>>> >>>> How to solve it? One possibility is to set master's hostname as KDC >>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>> use master's KDC. I'm absolutely not sure this will actually work >>>> but at least it allows to see if we are indeed dealing with >>>> inconsistent state of service principals' keys. >>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> When I tried to start the service again I got no response from >>>>>> tail of the log, but this is a repeating entry I see in the access >>>>>> log >>>>>> >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>> 127.0.0.1 to 127.0.0.1 >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>> nentries=0 etime=0 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>> >>>>>> Does anyone know what err=14 or err=49 are? >>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>> is ongoing. This is normal for SASL GSSAPI. >>>>> >>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>> It may also mean that LDAP server side was unable to process >>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>> for own service >>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>> KDC is down. >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>> 389-ds access log (buffered) to: >>>>>> >>>>>> 1. See if it is binding at all >>>>>> 2. See what the search is and what, if any, results were returned >>>>>> >>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>> what the error log shows >>>>>>>> >>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>> operation threads >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>> down internal subsystems and plugins >>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to >>>>>>>> stop >>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>> B2015.247.1737 starting up >>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>> Ok, that's good. >>>>>>> >>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>> example.com with your domain): >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>> cn=kerberos,dc=example,dc=com >>>>>>> >>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>> >>>>>>> If that returns nothing that's bad. >>>>>>> >>>>>>> If it succeeds I'd broaden the search base a bit to see what data >>>>>>> you do >>>>>>> have: >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>> >>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>> is just to see if you have data in the tree. >>>>>>> >>>>>>> Let us know if either or both turns up nothing. >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Hello all! >>>>>>>>> >>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>> been going on for sometime, I have all my certs figured out but >>>>>>>>> the krb5kdc service will not start. >>>>>>>>> >>>>>>>>> # service krb5kdc start >>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>> >>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for realm >>>>>>>>> ITMODEV.GOV >>>>>>>>> >>>>>>>>> I found this article online: >>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>> >>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried the >>>>>>>>> command >>>>>>>>> listed: >>>>>>>>> >>>>>>>>> # kdb5_util stash >>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>> >>>>>>>>> No further information found on the proceeding error above for >>>>>>>>> the kdb5_util command. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>> >>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>> anything else do not apply here at all. >>>>>>>> >>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>>> >>>>>>>> >>>>> -- >>>>> / 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 >>> > > From Christopher.Gronde at fincen.gov Tue Nov 10 16:16:48 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 16:16:48 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <5642157D.30900@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> Neither came back with anything # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=ldap/*.gov) # requesting: uid # # search result search: 2 result: 0 Success # numResponses: 1 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Tuesday, November 10, 2015 11:04 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: > Thank you! I should have caught that... > > I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 172.16.100.208 to 172.16.100.161 [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 etime=0 [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 This is the SASL bind. It thinks the principal in the Kerberos credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the code to look for something with uid=ldap/comipa01.itmodev.gov under dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 tag=48 nentries=0. nentries=0 means no entries matched the search criteria. You can do the search yourself with ldapsearch: ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' If you want to find out if there is some other ldap principal, do a search like this: ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> Ran into an error trying to set that >> >> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> : 260 >> >> modifying entry "cn=config" >> ldap_modify: Server is unwilling to perform (53) >> additional info: Unknown attribute nsslapd-acesslog-level >> will be ignored >> >> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >> Password: >> ldap_bind: Inappropriate authentication (48) >> >> -----Original Message----- >> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >> Sent: Tuesday, November 10, 2015 9:48 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> >> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >> yes, >> ldapmodify ... >> dn: cn=config >> changetype: modify >> replace: nsslapd-acesslog-level >> nsslapd-acesslog-level: 260 >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>> Krispenz >>> Sent: Tuesday, November 10, 2015 9:03 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>> Where can I verify or change the credentials it is trying to use? >>>>> Is it my LDAP password? >>>> No, according to your logs, it is your LDAP master trying to >>>> replicate (push changes) to your LDAP replica: >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>> Set nsslapd-acesslog-level: 260 >>> >>> and then look what internal searches are done during the gssapi >>> authentication >>>> If that is true, it would be ldap/ Kerberos principal >>>> talking to ldap/ Kerberos principal. If that fails, it >>>> means master and replica KDCs have different understanding of both >>>> ldap/ and ldap/ keys which most likely means keys >>>> were rotated on master and weren't propagated to replica. >>>> >>>> How to solve it? One possibility is to set master's hostname as KDC >>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>> use master's KDC. I'm absolutely not sure this will actually work >>>> but at least it allows to see if we are indeed dealing with >>>> inconsistent state of service principals' keys. >>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> When I tried to start the service again I got no response from >>>>>> tail of the log, but this is a repeating entry I see in the >>>>>> access log >>>>>> >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>> 127.0.0.1 to 127.0.0.1 >>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>> to >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>> nentries=0 etime=0 >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>> >>>>>> Does anyone know what err=14 or err=49 are? >>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>> is ongoing. This is normal for SASL GSSAPI. >>>>> >>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>> It may also mean that LDAP server side was unable to process >>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>> for own service >>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>> KDC is down. >>>>> >>>>>> -----Original Message----- >>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> ; Alexander Bokovoy >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>> 389-ds access log (buffered) to: >>>>>> >>>>>> 1. See if it is binding at all >>>>>> 2. See what the search is and what, if any, results were returned >>>>>> >>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>> >>>>>> rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>> what the error log shows >>>>>>>> >>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>> operation threads >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>> down internal subsystems and plugins >>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>> to stop >>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>> B2015.247.1737 starting up >>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>> Interfaces port 389 for LDAP requests >>>>>>> Ok, that's good. >>>>>>> >>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>> example.com with your domain): >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>> cn=kerberos,dc=example,dc=com >>>>>>> >>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>> >>>>>>> If that returns nothing that's bad. >>>>>>> >>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>> data you do >>>>>>> have: >>>>>>> >>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>> >>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>> is just to see if you have data in the tree. >>>>>>> >>>>>>> Let us know if either or both turns up nothing. >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Hello all! >>>>>>>>> >>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>> but the krb5kdc service will not start. >>>>>>>>> >>>>>>>>> # service krb5kdc start >>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>> >>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>> realm ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>> realm ITMODEV.GOV >>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>> realm ITMODEV.GOV >>>>>>>>> >>>>>>>>> I found this article online: >>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>> >>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>> the command >>>>>>>>> listed: >>>>>>>>> >>>>>>>>> # kdb5_util stash >>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>> >>>>>>>>> No further information found on the proceeding error above for >>>>>>>>> the kdb5_util command. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>> >>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>> anything else do not apply here at all. >>>>>>>> >>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>>> >>>>>>>> >>>>> -- >>>>> / 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 From rmeggins at redhat.com Tue Nov 10 16:27:14 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 09:27:14 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> Message-ID: <56421AE2.4080900@redhat.com> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: > Neither came back with anything > > # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=ldap/comipa01.itmodev.gov) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=ldap/*.gov) > # requesting: uid > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 That means this server has no LDAP service principals? I'm not sure how to recover IPA from this scenario. > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Tuesday, November 10, 2015 11:04 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >> Thank you! I should have caught that... >> >> I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... > > > [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from > 172.16.100.208 to 172.16.100.161 > [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 > nentries=0 etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 > etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 > > > > This is the SASL bind. It thinks the principal in the Kerberos credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the code to look for something with uid=ldap/comipa01.itmodev.gov under dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 > tag=48 nentries=0. nentries=0 means no entries matched the search criteria. > > You can do the search yourself with ldapsearch: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > > If you want to find out if there is some other ldap principal, do a search like this: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid > >>> Ran into an error trying to set that >>> >>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> : 260 >>> >>> modifying entry "cn=config" >>> ldap_modify: Server is unwilling to perform (53) >>> additional info: Unknown attribute nsslapd-acesslog-level >>> will be ignored >>> >>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>> Password: >>> ldap_bind: Inappropriate authentication (48) >>> >>> -----Original Message----- >>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>> Sent: Tuesday, November 10, 2015 9:48 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >>> yes, >>> ldapmodify ... >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> nsslapd-acesslog-level: 260 >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>> Krispenz >>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> Where can I verify or change the credentials it is trying to use? >>>>>> Is it my LDAP password? >>>>> No, according to your logs, it is your LDAP master trying to >>>>> replicate (push changes) to your LDAP replica: >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>> to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>>> Set nsslapd-acesslog-level: 260 >>>> >>>> and then look what internal searches are done during the gssapi >>>> authentication >>>>> If that is true, it would be ldap/ Kerberos principal >>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>> means master and replica KDCs have different understanding of both >>>>> ldap/ and ldap/ keys which most likely means keys >>>>> were rotated on master and weren't propagated to replica. >>>>> >>>>> How to solve it? One possibility is to set master's hostname as KDC >>>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>>> use master's KDC. I'm absolutely not sure this will actually work >>>>> but at least it allows to see if we are indeed dealing with >>>>> inconsistent state of service principals' keys. >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> When I tried to start the service again I got no response from >>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>> access log >>>>>>> >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>> to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>> nentries=0 etime=0 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>> >>>>>>> Does anyone know what err=14 or err=49 are? >>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>> >>>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>>> It may also mean that LDAP server side was unable to process >>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>> for own service >>>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>>> KDC is down. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>> 389-ds access log (buffered) to: >>>>>>> >>>>>>> 1. See if it is binding at all >>>>>>> 2. See what the search is and what, if any, results were returned >>>>>>> >>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>> what the error log shows >>>>>>>>> >>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>> operation threads >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>> down internal subsystems and plugins >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>> to stop >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>> B2015.247.1737 starting up >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>> Ok, that's good. >>>>>>>> >>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>> example.com with your domain): >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>> >>>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>>> >>>>>>>> If that returns nothing that's bad. >>>>>>>> >>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>> data you do >>>>>>>> have: >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>> >>>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>>> is just to see if you have data in the tree. >>>>>>>> >>>>>>>> Let us know if either or both turns up nothing. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Hello all! >>>>>>>>>> >>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>> >>>>>>>>>> # service krb5kdc start >>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>> >>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> >>>>>>>>>> I found this article online: >>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>> >>>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>> the command >>>>>>>>>> listed: >>>>>>>>>> >>>>>>>>>> # kdb5_util stash >>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>> >>>>>>>>>> No further information found on the proceeding error above for >>>>>>>>>> the kdb5_util command. >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>>> >>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>> anything else do not apply here at all. >>>>>>>>> >>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> / Alexander Bokovoy >>>>>>>>> >>>>>>>>> >>>>>> -- >>>>>> / 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 > From lkrispen at redhat.com Tue Nov 10 16:37:15 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 17:37:15 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56421AE2.4080900@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> Message-ID: <56421D3B.90704@redhat.com> what do you get if you search for "objectclass=krbprincipal" ? On 11/10/2015 05:27 PM, Rich Megginson wrote: > On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >> Neither came back with anything >> >> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=ldap/comipa01.itmodev.gov) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=ldap/*.gov) >> # requesting: uid >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 > > That means this server has no LDAP service principals? I'm not sure > how to recover IPA from this scenario. > >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson >> Sent: Tuesday, November 10, 2015 11:04 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>> Thank you! I should have caught that... >>> >>> I changed the log level and then restarted dirsrv and attempted to >>> start krb5kdc and got the following... >> >> >> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >> 172.16.100.208 to 172.16.100.161 >> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >> nentries=0 etime=1, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >> base="dc=itmodev,dc=gov" scope=2 >> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >> nentries=0 etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 >> etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >> >> >> >> This is the SASL bind. It thinks the principal in the Kerberos >> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the >> code to look for something with uid=ldap/comipa01.itmodev.gov under >> dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 >> tag=48 nentries=0. nentries=0 means no entries matched the search >> criteria. >> >> You can do the search yourself with ldapsearch: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> >> If you want to find out if there is some other ldap principal, do a >> search like this: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> >>>> Ran into an error trying to set that >>>> >>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> : 260 >>>> >>>> modifying entry "cn=config" >>>> ldap_modify: Server is unwilling to perform (53) >>>> additional info: Unknown attribute nsslapd-acesslog-level >>>> will be ignored >>>> >>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>> Password: >>>> ldap_bind: Inappropriate authentication (48) >>>> >>>> -----Original Message----- >>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>> How do I change that log setting? Is that done in LDAP? Using >>>>> ldapmodify? >>>> yes, >>>> ldapmodify ... >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> nsslapd-acesslog-level: 260 >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>> Is it my LDAP password? >>>>>> No, according to your logs, it is your LDAP master trying to >>>>>> replicate (push changes) to your LDAP replica: >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>>> to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>> err=49 could also be a result if the entry which is mapped from >>>>> the principal is not found in the directory. A bit more info could >>>>> be gained by enabling logging of internal searches. >>>>> Set nsslapd-acesslog-level: 260 >>>>> >>>>> and then look what internal searches are done during the gssapi >>>>> authentication >>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>> means master and replica KDCs have different understanding of both >>>>>> ldap/ and ldap/ keys which most likely means keys >>>>>> were rotated on master and weren't propagated to replica. >>>>>> >>>>>> How to solve it? One possibility is to set master's hostname as KDC >>>>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>>>> use master's KDC. I'm absolutely not sure this will actually work >>>>>> but at least it allows to see if we are indeed dealing with >>>>>> inconsistent state of service principals' keys. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> When I tried to start the service again I got no response from >>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>> access log >>>>>>>> >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>>> to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>> nentries=0 etime=0 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>> >>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>>> >>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>> incorrect. >>>>>>> It may also mean that LDAP server side was unable to process >>>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>>> for own service >>>>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>>>> KDC is down. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>> 389-ds access log (buffered) to: >>>>>>>> >>>>>>>> 1. See if it is binding at all >>>>>>>> 2. See what the search is and what, if any, results were returned >>>>>>>> >>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>>> what the error log shows >>>>>>>>>> >>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>>> operation threads >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>> down internal subsystems and plugins >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>>> to stop >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>> Ok, that's good. >>>>>>>>> >>>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>>> example.com with your domain): >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>> >>>>>>>>> (don't post the output as it would include the kerberos master >>>>>>>>> key). >>>>>>>>> >>>>>>>>> If that returns nothing that's bad. >>>>>>>>> >>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>> data you do >>>>>>>>> have: >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>> >>>>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>>>> is just to see if you have data in the tree. >>>>>>>>> >>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Hello all! >>>>>>>>>>> >>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>> >>>>>>>>>>> # service krb5kdc start >>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>> [FAILED] >>>>>>>>>>> >>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> >>>>>>>>>>> I found this article online: >>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>>> >>>>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>>> the command >>>>>>>>>>> listed: >>>>>>>>>>> >>>>>>>>>>> # kdb5_util stash >>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>> >>>>>>>>>>> No further information found on the proceeding error above for >>>>>>>>>>> the kdb5_util command. >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>> please. >>>>>>>>>> >>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>> anything else do not apply here at all. >>>>>>>>>> >>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>> -- >>>>>>> / 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 >> > From mbabinsk at redhat.com Tue Nov 10 16:39:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 17:39:05 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> Message-ID: <56421DA9.9080506@redhat.com> On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote: > Neither came back with anything > > # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=ldap/comipa01.itmodev.gov) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=ldap/*.gov) > # requesting: uid > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > I think that you should search for 'krbprincipalname' attribute when you want to find out whether you have the proper Kerberos principal present, like so: ldapsearch -Y GSSAPI -b 'dc=ipa,dc=test' '(krbprincipalname=ldap/master1.ipa.test*)' > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Tuesday, November 10, 2015 11:04 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >> Thank you! I should have caught that... >> >> I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... > > > [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from > 172.16.100.208 to 172.16.100.161 > [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 > nentries=0 etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 > etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 > > > > This is the SASL bind. It thinks the principal in the Kerberos credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the code to look for something with uid=ldap/comipa01.itmodev.gov under dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 > tag=48 nentries=0. nentries=0 means no entries matched the search criteria. > > You can do the search yourself with ldapsearch: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > > If you want to find out if there is some other ldap principal, do a search like this: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid > >>> Ran into an error trying to set that >>> >>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> : 260 >>> >>> modifying entry "cn=config" >>> ldap_modify: Server is unwilling to perform (53) >>> additional info: Unknown attribute nsslapd-acesslog-level >>> will be ignored >>> >>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>> Password: >>> ldap_bind: Inappropriate authentication (48) >>> >>> -----Original Message----- >>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>> Sent: Tuesday, November 10, 2015 9:48 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >>> yes, >>> ldapmodify ... >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> nsslapd-acesslog-level: 260 >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>> Krispenz >>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> Where can I verify or change the credentials it is trying to use? >>>>>> Is it my LDAP password? >>>>> No, according to your logs, it is your LDAP master trying to >>>>> replicate (push changes) to your LDAP replica: >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>> to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>>> Set nsslapd-acesslog-level: 260 >>>> >>>> and then look what internal searches are done during the gssapi >>>> authentication >>>>> If that is true, it would be ldap/ Kerberos principal >>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>> means master and replica KDCs have different understanding of both >>>>> ldap/ and ldap/ keys which most likely means keys >>>>> were rotated on master and weren't propagated to replica. >>>>> >>>>> How to solve it? One possibility is to set master's hostname as KDC >>>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>>> use master's KDC. I'm absolutely not sure this will actually work >>>>> but at least it allows to see if we are indeed dealing with >>>>> inconsistent state of service principals' keys. >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> When I tried to start the service again I got no response from >>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>> access log >>>>>>> >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>> to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>> nentries=0 etime=0 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>> >>>>>>> Does anyone know what err=14 or err=49 are? >>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>> >>>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>>> It may also mean that LDAP server side was unable to process >>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>> for own service >>>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>>> KDC is down. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>> 389-ds access log (buffered) to: >>>>>>> >>>>>>> 1. See if it is binding at all >>>>>>> 2. See what the search is and what, if any, results were returned >>>>>>> >>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>> what the error log shows >>>>>>>>> >>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>> operation threads >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>> down internal subsystems and plugins >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>> to stop >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>> B2015.247.1737 starting up >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>> Ok, that's good. >>>>>>>> >>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>> example.com with your domain): >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>> >>>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>>> >>>>>>>> If that returns nothing that's bad. >>>>>>>> >>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>> data you do >>>>>>>> have: >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>> >>>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>>> is just to see if you have data in the tree. >>>>>>>> >>>>>>>> Let us know if either or both turns up nothing. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Hello all! >>>>>>>>>> >>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>> >>>>>>>>>> # service krb5kdc start >>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>> >>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> >>>>>>>>>> I found this article online: >>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>> >>>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>> the command >>>>>>>>>> listed: >>>>>>>>>> >>>>>>>>>> # kdb5_util stash >>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>> >>>>>>>>>> No further information found on the proceeding error above for >>>>>>>>>> the kdb5_util command. >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>>> >>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>> anything else do not apply here at all. >>>>>>>>> >>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> / Alexander Bokovoy >>>>>>>>> >>>>>>>>> >>>>>> -- >>>>>> / 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 > > -- Martin^3 Babinsky From rmeggins at redhat.com Tue Nov 10 16:40:57 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 09:40:57 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56421DA9.9080506@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421DA9.9080506@redhat.com> Message-ID: <56421E19.4060702@redhat.com> On 11/10/2015 09:39 AM, Martin Babinsky wrote: > On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote: >> Neither came back with anything >> >> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=ldap/comipa01.itmodev.gov) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=ldap/*.gov) >> # requesting: uid >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> > I think that you should search for 'krbprincipalname' attribute when > you want to find out whether you have the proper Kerberos principal > present, like so: > > ldapsearch -Y GSSAPI -b 'dc=ipa,dc=test' > '(krbprincipalname=ldap/master1.ipa.test*)' That means there is a bug in the SASL mappings - why is the SASL mapping searching for uid=ldap/... instead of krbprincipalname=ldap/... ???? > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson >> Sent: Tuesday, November 10, 2015 11:04 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>> Thank you! I should have caught that... >>> >>> I changed the log level and then restarted dirsrv and attempted to >>> start krb5kdc and got the following... >> >> >> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >> 172.16.100.208 to 172.16.100.161 >> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >> nentries=0 etime=1, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >> base="dc=itmodev,dc=gov" scope=2 >> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >> nentries=0 etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 >> etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >> >> >> >> This is the SASL bind. It thinks the principal in the Kerberos >> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the >> code to look for something with uid=ldap/comipa01.itmodev.gov under >> dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 >> tag=48 nentries=0. nentries=0 means no entries matched the search >> criteria. >> >> You can do the search yourself with ldapsearch: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> >> If you want to find out if there is some other ldap principal, do a >> search like this: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> >>>> Ran into an error trying to set that >>>> >>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> : 260 >>>> >>>> modifying entry "cn=config" >>>> ldap_modify: Server is unwilling to perform (53) >>>> additional info: Unknown attribute nsslapd-acesslog-level >>>> will be ignored >>>> >>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>> Password: >>>> ldap_bind: Inappropriate authentication (48) >>>> >>>> -----Original Message----- >>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>> How do I change that log setting? Is that done in LDAP? Using >>>>> ldapmodify? >>>> yes, >>>> ldapmodify ... >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> nsslapd-acesslog-level: 260 >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>> Is it my LDAP password? >>>>>> No, according to your logs, it is your LDAP master trying to >>>>>> replicate (push changes) to your LDAP replica: >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>>> to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>> err=49 could also be a result if the entry which is mapped from >>>>> the principal is not found in the directory. A bit more info could >>>>> be gained by enabling logging of internal searches. >>>>> Set nsslapd-acesslog-level: 260 >>>>> >>>>> and then look what internal searches are done during the gssapi >>>>> authentication >>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>> means master and replica KDCs have different understanding of both >>>>>> ldap/ and ldap/ keys which most likely means keys >>>>>> were rotated on master and weren't propagated to replica. >>>>>> >>>>>> How to solve it? One possibility is to set master's hostname as KDC >>>>>> address in krb5.conf on replica, forcing LDAP server on replica to >>>>>> use master's KDC. I'm absolutely not sure this will actually work >>>>>> but at least it allows to see if we are indeed dealing with >>>>>> inconsistent state of service principals' keys. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: Rob Crittenden ; freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> When I tried to start the service again I got no response from >>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>> access log >>>>>>>> >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from >>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from >>>>>>>> to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>> nentries=0 etime=0 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>> >>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>>> >>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>> incorrect. >>>>>>> It may also mean that LDAP server side was unable to process >>>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>>> for own service >>>>>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos >>>>>>> KDC is down. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>> 389-ds access log (buffered) to: >>>>>>>> >>>>>>>> 1. See if it is binding at all >>>>>>>> 2. See what the search is and what, if any, results were returned >>>>>>>> >>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>>> what the error log shows >>>>>>>>>> >>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on All >>>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>>> operation threads >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>> down internal subsystems and plugins >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>>> to stop >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on All >>>>>>>>>> Interfaces port 389 for LDAP requests >>>>>>>>> Ok, that's good. >>>>>>>>> >>>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>>> example.com with your domain): >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>> >>>>>>>>> (don't post the output as it would include the kerberos master >>>>>>>>> key). >>>>>>>>> >>>>>>>>> If that returns nothing that's bad. >>>>>>>>> >>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>> data you do >>>>>>>>> have: >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>> >>>>>>>>> I picked groups because usually groups << users in numbers. This >>>>>>>>> is just to see if you have data in the tree. >>>>>>>>> >>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Hello all! >>>>>>>>>>> >>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>> >>>>>>>>>>> # service krb5kdc start >>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>> [FAILED] >>>>>>>>>>> >>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> >>>>>>>>>>> I found this article online: >>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>>> >>>>>>>>>>> Which stated it might be because The slave KDC does not have a >>>>>>>>>>> stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>>> the command >>>>>>>>>>> listed: >>>>>>>>>>> >>>>>>>>>>> # kdb5_util stash >>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>> >>>>>>>>>>> No further information found on the proceeding error above for >>>>>>>>>>> the kdb5_util command. >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>> please. >>>>>>>>>> >>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>> anything else do not apply here at all. >>>>>>>>>> >>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>> -- >>>>>>> / 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 >> >> > > From Christopher.Gronde at fincen.gov Tue Nov 10 16:42:29 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 16:42:29 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56421D3B.90704@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' # search result search: 2 result: 0 Success # numResponses: 142 # numEntries: 141 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz Sent: Tuesday, November 10, 2015 11:37 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) what do you get if you search for "objectclass=krbprincipal" ? On 11/10/2015 05:27 PM, Rich Megginson wrote: > On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >> Neither came back with anything >> >> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # filter: >> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP >> Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # filter: >> (uid=ldap/*.gov) # requesting: uid # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 > > That means this server has no LDAP service principals? I'm not sure > how to recover IPA from this scenario. > >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson >> Sent: Tuesday, November 10, 2015 11:04 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>> Thank you! I should have caught that... >>> >>> I changed the log level and then restarted dirsrv and attempted to >>> start krb5kdc and got the following... >> >> >> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >> 172.16.100.208 to 172.16.100.161 >> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >> nentries=0 etime=1, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >> base="dc=itmodev,dc=gov" scope=2 >> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >> nentries=0 etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >> nentries=0 >> etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >> >> >> >> This is the SASL bind. It thinks the principal in the Kerberos >> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the >> code to look for something with uid=ldap/comipa01.itmodev.gov under >> dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 >> tag=48 nentries=0. nentries=0 means no entries matched the search >> criteria. >> >> You can do the search yourself with ldapsearch: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> >> If you want to find out if there is some other ldap principal, do a >> search like this: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> >>>> Ran into an error trying to set that >>>> >>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> : 260 >>>> >>>> modifying entry "cn=config" >>>> ldap_modify: Server is unwilling to perform (53) >>>> additional info: Unknown attribute >>>> nsslapd-acesslog-level will be ignored >>>> >>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>> Password: >>>> ldap_bind: Inappropriate authentication (48) >>>> >>>> -----Original Message----- >>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>> How do I change that log setting? Is that done in LDAP? Using >>>>> ldapmodify? >>>> yes, >>>> ldapmodify ... >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> nsslapd-acesslog-level: 260 >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>> Is it my LDAP password? >>>>>> No, according to your logs, it is your LDAP master trying to >>>>>> replicate (push changes) to your LDAP replica: >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>> from to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>> err=49 could also be a result if the entry which is mapped from >>>>> the principal is not found in the directory. A bit more info could >>>>> be gained by enabling logging of internal searches. >>>>> Set nsslapd-acesslog-level: 260 >>>>> >>>>> and then look what internal searches are done during the gssapi >>>>> authentication >>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>> means master and replica KDCs have different understanding of >>>>>> both ldap/ and ldap/ keys which most likely >>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>> >>>>>> How to solve it? One possibility is to set master's hostname as >>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>> actually work but at least it allows to see if we are indeed >>>>>> dealing with inconsistent state of service principals' keys. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: Rob Crittenden ; >>>>>>> freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> When I tried to start the service again I got no response from >>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>> access log >>>>>>>> >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>> from >>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>> from to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>> nentries=0 etime=0 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>> >>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>> >>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>> incorrect. >>>>>>> It may also mean that LDAP server side was unable to process >>>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>>> for own service >>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>> Kerberos KDC is down. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>> 389-ds access log (buffered) to: >>>>>>>> >>>>>>>> 1. See if it is binding at all >>>>>>>> 2. See what the search is and what, if any, results were >>>>>>>> returned >>>>>>>> >>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>>> what the error log shows >>>>>>>>>> >>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend >>>>>>>>>> to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>> signaling operation threads >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>> down internal subsystems and plugins >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>>> to stop >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>> stopped >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend >>>>>>>>>> to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>> Ok, that's good. >>>>>>>>> >>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>> (substitute example.com with your domain): >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>> >>>>>>>>> (don't post the output as it would include the kerberos master >>>>>>>>> key). >>>>>>>>> >>>>>>>>> If that returns nothing that's bad. >>>>>>>>> >>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>> data you do >>>>>>>>> have: >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>> >>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>> >>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Hello all! >>>>>>>>>>> >>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>> >>>>>>>>>>> # service krb5kdc start >>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>> [FAILED] >>>>>>>>>>> >>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> >>>>>>>>>>> I found this article online: >>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtm >>>>>>>>>>> l >>>>>>>>>>> >>>>>>>>>>> Which stated it might be because The slave KDC does not have >>>>>>>>>>> a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>> Tried the command >>>>>>>>>>> listed: >>>>>>>>>>> >>>>>>>>>>> # kdb5_util stash >>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>> >>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>> please. >>>>>>>>>> >>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>> anything else do not apply here at all. >>>>>>>>>> >>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>> -- >>>>>>> / 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 From Christopher.Gronde at fincen.gov Tue Nov 10 16:49:15 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 16:49:15 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56421DA9.9080506@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421DA9.9080506@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BF15@hqexdb01.hqfincen.gov> Note comipa01 is the master and comipa02 is the replica that is having the KDC issue # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa01.itmodev.gov*)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (krbprincipalname=ldap/comipa01.itmodev.gov*) # requesting: ALL # # ldap/comipa01.itmodev.gov at ITMODEV.GOV, services, accounts, itmodev.gov dn: krbprincipalname=ldap/comipa01.itmodev.gov at ITMODEV.GOV,cn=services,cn=acco unts,dc=itmodev,dc=gov krbLastSuccessfulAuth: 20151015230212Z ipaKrbPrincipalAlias: ldap/comipa01.itmodev.gov at ITMODEV.GOV krbExtraData:: AAL6CaBOYWRtaW4vYWRtaW5ASVRNT0RFVi5HT1YA krbExtraData:: AAgBAA== userCertificate:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX krbPasswordExpiration: 19700101000000Z ipaUniqueID: 15a897e8-fb11-11e0-b8e5-001a4a106404 krbLastPwdChange: 20111020114602Z krbPrincipalName: ldap/comipa01.itmodev.gov at ITMODEV.GOV krbLoginFailedCount: 0 managedBy: fqdn=comipa01.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go v objectClass: ipaobject objectClass: top objectClass: ipaservice objectClass: pkiuser objectClass: krbprincipal objectClass: krbprincipalaux objectClass: krbTicketPolicyAux objectClass: ipakrbprincipal krbPrincipalKey:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at comipa02 ~]# # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa02.itmodev.gov*)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (krbprincipalname=ldap/comipa02.itmodev.gov*) # requesting: ALL # # ldap/comipa02.itmodev.gov at ITMODEV.GOV, services, accounts, itmodev.gov dn: krbprincipalname=ldap/comipa02.itmodev.gov at ITMODEV.GOV,cn=services,cn=acco unts,dc=itmodev,dc=gov krbLastSuccessfulAuth: 20150921160115Z ipaKrbPrincipalAlias: ldap/comipa02.itmodev.gov at ITMODEV.GOV userCertificate:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX krbExtraData:: AAgBAA== krbLastPwdChange: 20111020180803Z krbPasswordExpiration: 19700101000000Z krbPrincipalKey:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX krbLoginFailedCount: 0 objectClass: ipaobject objectClass: top objectClass: ipaservice objectClass: pkiuser objectClass: krbprincipal objectClass: krbprincipalaux objectClass: krbTicketPolicyAux objectClass: ipakrbprincipal managedBy: fqdn=comipa02.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go v krbPrincipalName: ldap/comipa02.itmodev.gov at ITMODEV.GOV ipaUniqueID: 739e600a-fb46-11e0-a4b9-5254004d91a8 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at comipa02 ~]# -----Original Message----- From: Martin Babinsky [mailto:mbabinsk at redhat.com] Sent: Tuesday, November 10, 2015 11:39 AM To: Gronde, Christopher (Contractor) ; Rich Megginson ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote: > Neither came back with anything > > # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree # filter: > (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory > manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree # filter: > (uid=ldap/*.gov) # requesting: uid # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > I think that you should search for 'krbprincipalname' attribute when you want to find out whether you have the proper Kerberos principal present, like so: ldapsearch -Y GSSAPI -b 'dc=ipa,dc=test' '(krbprincipalname=ldap/master1.ipa.test*)' > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Tuesday, November 10, 2015 11:04 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >> Thank you! I should have caught that... >> >> I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... > > > [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from > 172.16.100.208 to 172.16.100.161 > [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 > nentries=0 etime=1, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH > base="dc=itmodev,dc=gov" scope=2 > filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL > [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 > nentries=0 etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 > nentries=0 > etime=0 > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND > [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 > > > > This is the SASL bind. It thinks the principal in the Kerberos > credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the > code to look for something with uid=ldap/comipa01.itmodev.gov under > dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 > tag=48 nentries=0. nentries=0 means no entries matched the search criteria. > > You can do the search yourself with ldapsearch: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' > > If you want to find out if there is some other ldap principal, do a search like this: > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b > "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid > >>> Ran into an error trying to set that >>> >>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> : 260 >>> >>> modifying entry "cn=config" >>> ldap_modify: Server is unwilling to perform (53) >>> additional info: Unknown attribute nsslapd-acesslog-level >>> will be ignored >>> >>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>> Password: >>> ldap_bind: Inappropriate authentication (48) >>> >>> -----Original Message----- >>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>> Sent: Tuesday, November 10, 2015 9:48 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> >>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >>> yes, >>> ldapmodify ... >>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-acesslog-level >>> nsslapd-acesslog-level: 260 >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>> Krispenz >>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>> Where can I verify or change the credentials it is trying to use? >>>>>> Is it my LDAP password? >>>>> No, according to your logs, it is your LDAP master trying to >>>>> replicate (push changes) to your LDAP replica: >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>> from to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>>> Set nsslapd-acesslog-level: 260 >>>> >>>> and then look what internal searches are done during the gssapi >>>> authentication >>>>> If that is true, it would be ldap/ Kerberos principal >>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>> means master and replica KDCs have different understanding of both >>>>> ldap/ and ldap/ keys which most likely means keys >>>>> were rotated on master and weren't propagated to replica. >>>>> >>>>> How to solve it? One possibility is to set master's hostname as >>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>> actually work but at least it allows to see if we are indeed >>>>> dealing with inconsistent state of service principals' keys. >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: Rob Crittenden ; >>>>>> freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> When I tried to start the service again I got no response from >>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>> access log >>>>>>> >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>> from >>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>> from to >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>> nentries=0 etime=0 >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>> >>>>>>> Does anyone know what err=14 or err=49 are? >>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>> >>>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>>> It may also mean that LDAP server side was unable to process >>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>> for own service >>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>> Kerberos KDC is down. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> ; Alexander Bokovoy >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>> 389-ds access log (buffered) to: >>>>>>> >>>>>>> 1. See if it is binding at all >>>>>>> 2. See what the search is and what, if any, results were >>>>>>> returned >>>>>>> >>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>> what the error log shows >>>>>>>>> >>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>> operation threads >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>> down internal subsystems and plugins >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>> to stop >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>> stopped >>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>> B2015.247.1737 starting up >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>> Ok, that's good. >>>>>>>> >>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>> example.com with your domain): >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>> >>>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>>> >>>>>>>> If that returns nothing that's bad. >>>>>>>> >>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>> data you do >>>>>>>> have: >>>>>>>> >>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>> >>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>> This is just to see if you have data in the tree. >>>>>>>> >>>>>>>> Let us know if either or both turns up nothing. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Hello all! >>>>>>>>>> >>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>> >>>>>>>>>> # service krb5kdc start >>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>> >>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>> >>>>>>>>>> I found this article online: >>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>> >>>>>>>>>> Which stated it might be because The slave KDC does not have >>>>>>>>>> a stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>> the command >>>>>>>>>> listed: >>>>>>>>>> >>>>>>>>>> # kdb5_util stash >>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>> >>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>> for the kdb5_util command. >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>>> >>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>> anything else do not apply here at all. >>>>>>>>> >>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> / Alexander Bokovoy >>>>>>>>> >>>>>>>>> >>>>>> -- >>>>>> / 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 > > -- Martin^3 Babinsky From rcritten at redhat.com Tue Nov 10 16:51:59 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2015 11:51:59 -0500 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> Message-ID: <564220AF.9010701@redhat.com> Gronde, Christopher (Contractor) wrote: > This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' > > > # search result > search: 2 > result: 0 Success > > # numResponses: 142 > # numEntries: 141 Right, we need to see the sasl mapping: $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, November 10, 2015 11:37 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > what do you get if you search for "objectclass=krbprincipal" ? > > On 11/10/2015 05:27 PM, Rich Megginson wrote: >> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>> Neither came back with anything >>> >>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 1 >>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP >>> Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (uid=ldap/*.gov) # requesting: uid # >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 1 >> >> That means this server has no LDAP service principals? I'm not sure >> how to recover IPA from this scenario. >> >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson >>> Sent: Tuesday, November 10, 2015 11:04 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>> Thank you! I should have caught that... >>>> >>>> I changed the log level and then restarted dirsrv and attempted to >>>> start krb5kdc and got the following... >>> >>> >>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>> 172.16.100.208 to 172.16.100.161 >>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=1, SASL bind in progress >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>> base="dc=itmodev,dc=gov" scope=2 >>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >>> nentries=0 etime=0 >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>> nentries=0 >>> etime=0 >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>> >>> >>> >>> This is the SASL bind. It thinks the principal in the Kerberos >>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the >>> code to look for something with uid=ldap/comipa01.itmodev.gov under >>> dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 >>> tag=48 nentries=0. nentries=0 means no entries matched the search >>> criteria. >>> >>> You can do the search yourself with ldapsearch: >>> >>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>> >>> If you want to find out if there is some other ldap principal, do a >>> search like this: >>> >>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>> >>>>> Ran into an error trying to set that >>>>> >>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>> dn: cn=config >>>>> changetype: modify >>>>> replace: nsslapd-acesslog-level >>>>> : 260 >>>>> >>>>> modifying entry "cn=config" >>>>> ldap_modify: Server is unwilling to perform (53) >>>>> additional info: Unknown attribute >>>>> nsslapd-acesslog-level will be ignored >>>>> >>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>> Password: >>>>> ldap_bind: Inappropriate authentication (48) >>>>> >>>>> -----Original Message----- >>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>> ldapmodify? >>>>> yes, >>>>> ldapmodify ... >>>>> dn: cn=config >>>>> changetype: modify >>>>> replace: nsslapd-acesslog-level >>>>> nsslapd-acesslog-level: 260 >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com >>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>> Krispenz >>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> >>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>> Is it my LDAP password? >>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>> from to >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>> err=49 could also be a result if the entry which is mapped from >>>>>> the principal is not found in the directory. A bit more info could >>>>>> be gained by enabling logging of internal searches. >>>>>> Set nsslapd-acesslog-level: 260 >>>>>> >>>>>> and then look what internal searches are done during the gssapi >>>>>> authentication >>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>> means master and replica KDCs have different understanding of >>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>> >>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>> actually work but at least it allows to see if we are indeed >>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: Rob Crittenden ; >>>>>>>> freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> When I tried to start the service again I got no response from >>>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>>> access log >>>>>>>>> >>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>> from >>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>> from to >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>> nentries=0 etime=0 >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>> >>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>> >>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>> incorrect. >>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>>>> for own service >>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>> Kerberos KDC is down. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>> >>>>>>>>> 1. See if it is binding at all >>>>>>>>> 2. See what the search is and what, if any, results were >>>>>>>>> returned >>>>>>>>> >>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>>>> what the error log shows >>>>>>>>>>> >>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend >>>>>>>>>>> to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>> signaling operation threads >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>>> down internal subsystems and plugins >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>>>> to stop >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>> stopped >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend >>>>>>>>>>> to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>> Ok, that's good. >>>>>>>>>> >>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>> >>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>> >>>>>>>>>> (don't post the output as it would include the kerberos master >>>>>>>>>> key). >>>>>>>>>> >>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>> >>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>> data you do >>>>>>>>>> have: >>>>>>>>>> >>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>> >>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>> >>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>> authentication error) >>>>>>>>>>> >>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> Hello all! >>>>>>>>>>>> >>>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>>> >>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>>> [FAILED] >>>>>>>>>>>> >>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> >>>>>>>>>>>> I found this article online: >>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtm >>>>>>>>>>>> l >>>>>>>>>>>> >>>>>>>>>>>> Which stated it might be because The slave KDC does not have >>>>>>>>>>>> a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>> Tried the command >>>>>>>>>>>> listed: >>>>>>>>>>>> >>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>> >>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>> >>>>>>>>>>>> Any thoughts? >>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>> please. >>>>>>>>>>> >>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>>> anything else do not apply here at all. >>>>>>>>>>> >>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> -- >>>>>>>> / 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 > > From rmeggins at redhat.com Tue Nov 10 16:52:25 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 09:52:25 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BF15@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151109155052.GC1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421DA9.9080506@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF15@hqexdb01.hqfincen.gov> Message-ID: <564220C9.2050905@redhat.com> On 11/10/2015 09:49 AM, Gronde, Christopher (Contractor) wrote: > Note comipa01 is the master and comipa02 is the replica that is having the KDC issue > > # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa01.itmodev.gov*)' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (krbprincipalname=ldap/comipa01.itmodev.gov*) > # requesting: ALL > # > > # ldap/comipa01.itmodev.gov at ITMODEV.GOV, services, accounts, itmodev.gov > dn: krbprincipalname=ldap/comipa01.itmodev.gov at ITMODEV.GOV,cn=services,cn=acco > unts,dc=itmodev,dc=gov > krbLastSuccessfulAuth: 20151015230212Z > ipaKrbPrincipalAlias: ldap/comipa01.itmodev.gov at ITMODEV.GOV > krbExtraData:: AAL6CaBOYWRtaW4vYWRtaW5ASVRNT0RFVi5HT1YA > krbExtraData:: AAgBAA== > userCertificate:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > krbPasswordExpiration: 19700101000000Z > ipaUniqueID: 15a897e8-fb11-11e0-b8e5-001a4a106404 > krbLastPwdChange: 20111020114602Z > krbPrincipalName: ldap/comipa01.itmodev.gov at ITMODEV.GOV > krbLoginFailedCount: 0 > managedBy: fqdn=comipa01.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go > v > objectClass: ipaobject > objectClass: top > objectClass: ipaservice > objectClass: pkiuser > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: krbTicketPolicyAux > objectClass: ipakrbprincipal > krbPrincipalKey:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at comipa02 ~]# > > # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa02.itmodev.gov*)' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (krbprincipalname=ldap/comipa02.itmodev.gov*) > # requesting: ALL > # > > # ldap/comipa02.itmodev.gov at ITMODEV.GOV, services, accounts, itmodev.gov > dn: krbprincipalname=ldap/comipa02.itmodev.gov at ITMODEV.GOV,cn=services,cn=acco > unts,dc=itmodev,dc=gov > krbLastSuccessfulAuth: 20150921160115Z > ipaKrbPrincipalAlias: ldap/comipa02.itmodev.gov at ITMODEV.GOV > userCertificate:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > krbExtraData:: AAgBAA== > krbLastPwdChange: 20111020180803Z > krbPasswordExpiration: 19700101000000Z > krbPrincipalKey:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXREDACTEDXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > krbLoginFailedCount: 0 > objectClass: ipaobject > objectClass: top > objectClass: ipaservice > objectClass: pkiuser > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: krbTicketPolicyAux > objectClass: ipakrbprincipal > managedBy: fqdn=comipa02.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go > v > krbPrincipalName: ldap/comipa02.itmodev.gov at ITMODEV.GOV > ipaUniqueID: 739e600a-fb46-11e0-a4b9-5254004d91a8 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at comipa02 ~]# Ok. This sure looks like a SASL mapping issue - the map should be using krbPrincipalName instead of uid. > > -----Original Message----- > From: Martin Babinsky [mailto:mbabinsk at redhat.com] > Sent: Tuesday, November 10, 2015 11:39 AM > To: Gronde, Christopher (Contractor) ; Rich Megginson ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote: >> Neither came back with anything >> >> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # filter: >> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # filter: >> (uid=ldap/*.gov) # requesting: uid # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> > I think that you should search for 'krbprincipalname' attribute when you want to find out whether you have the proper Kerberos principal present, like so: > > ldapsearch -Y GSSAPI -b 'dc=ipa,dc=test' > '(krbprincipalname=ldap/master1.ipa.test*)' > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson >> Sent: Tuesday, November 10, 2015 11:04 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>> Thank you! I should have caught that... >>> >>> I changed the log level and then restarted dirsrv and attempted to start krb5kdc and got the following... >> >> >> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >> 172.16.100.208 to 172.16.100.161 >> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >> nentries=0 etime=1, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >> base="dc=itmodev,dc=gov" scope=2 >> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >> nentries=0 etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >> nentries=0 >> etime=0 >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >> >> >> >> This is the SASL bind. It thinks the principal in the Kerberos >> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the >> code to look for something with uid=ldap/comipa01.itmodev.gov under >> dc=itmodev,dc=gov. However, this entry is not found: RESULT err=0 >> tag=48 nentries=0. nentries=0 means no entries matched the search criteria. >> >> You can do the search yourself with ldapsearch: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >> >> If you want to find out if there is some other ldap principal, do a search like this: >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >> >>>> Ran into an error trying to set that >>>> >>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> : 260 >>>> >>>> modifying entry "cn=config" >>>> ldap_modify: Server is unwilling to perform (53) >>>> additional info: Unknown attribute nsslapd-acesslog-level >>>> will be ignored >>>> >>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>> Password: >>>> ldap_bind: Inappropriate authentication (48) >>>> >>>> -----Original Message----- >>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> >>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>> How do I change that log setting? Is that done in LDAP? Using ldapmodify? >>>> yes, >>>> ldapmodify ... >>>> dn: cn=config >>>> changetype: modify >>>> replace: nsslapd-acesslog-level >>>> nsslapd-acesslog-level: 260 >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>> Is it my LDAP password? >>>>>> No, according to your logs, it is your LDAP master trying to >>>>>> replicate (push changes) to your LDAP replica: >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>> from to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>> err=49 could also be a result if the entry which is mapped from the principal is not found in the directory. A bit more info could be gained by enabling logging of internal searches. >>>>> Set nsslapd-acesslog-level: 260 >>>>> >>>>> and then look what internal searches are done during the gssapi >>>>> authentication >>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>> means master and replica KDCs have different understanding of both >>>>>> ldap/ and ldap/ keys which most likely means keys >>>>>> were rotated on master and weren't propagated to replica. >>>>>> >>>>>> How to solve it? One possibility is to set master's hostname as >>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>> actually work but at least it allows to see if we are indeed >>>>>> dealing with inconsistent state of service principals' keys. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: Rob Crittenden ; >>>>>>> freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> When I tried to start the service again I got no response from >>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>> access log >>>>>>>> >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>> from >>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>> from to >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl >>>>>>>> version=3 mech=GSSAPI >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>> nentries=0 etime=0 >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>> >>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>> err=14 means SASL bind in progress -- i.e. multi-round processing >>>>>>> is ongoing. This is normal for SASL GSSAPI. >>>>>>> >>>>>>> err=49 is wrong password or username, i.e. credentials were incorrect. >>>>>>> It may also mean that LDAP server side was unable to process >>>>>>> Kerberos negotiation due to not having a current Kerberos ticket >>>>>>> for own service >>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>> Kerberos KDC is down. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> ; Alexander Bokovoy >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>> 389-ds access log (buffered) to: >>>>>>>> >>>>>>>> 1. See if it is binding at all >>>>>>>> 2. See what the search is and what, if any, results were >>>>>>>> returned >>>>>>>> >>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this is >>>>>>>>>> what the error log shows >>>>>>>>>> >>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling >>>>>>>>>> operation threads >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>> down internal subsystems and plugins >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads >>>>>>>>>> to stop >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>> stopped >>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache >>>>>>>>>> size 10485760B is less than db size 28016640B; We recommend to >>>>>>>>>> increase the entry cache size nsslapd-cachememsize. >>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>> Ok, that's good. >>>>>>>>> >>>>>>>>> I'd do something like this to see what is in the db (substitute >>>>>>>>> example.com with your domain): >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>> >>>>>>>>> (don't post the output as it would include the kerberos master key). >>>>>>>>> >>>>>>>>> If that returns nothing that's bad. >>>>>>>>> >>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>> data you do >>>>>>>>> have: >>>>>>>>> >>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>> >>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>> >>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Hello all! >>>>>>>>>>> >>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>> >>>>>>>>>>> # service krb5kdc start >>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>> >>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>> >>>>>>>>>>> I found this article online: >>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml >>>>>>>>>>> >>>>>>>>>>> Which stated it might be because The slave KDC does not have >>>>>>>>>>> a stash file (.k5.EXAMPLE.COM). You need to create one. Tried >>>>>>>>>>> the command >>>>>>>>>>> listed: >>>>>>>>>>> >>>>>>>>>>> # kdb5_util stash >>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>> >>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>> First: don't use instructions which are not related to IPA, please. >>>>>>>>>> >>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>> anything else do not apply here at all. >>>>>>>>>> >>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. Does >>>>>>>>>> LDAP server work on the replica? What is in its error log >>>>>>>>>> (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>> -- >>>>>>> / 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 >> >> > > -- > Martin^3 Babinsky > From Christopher.Gronde at fincen.gov Tue Nov 10 16:54:45 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 16:54:45 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <564220AF.9010701@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828B6B1@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> # ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # mapping, sasl, config dn: cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: mapping # Full Principal, mapping, sasl, config dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: \(.*\)@\(.*\) cn: Full Principal nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) # Kerberos uid mapping, mapping, sasl, config dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: Kerberos uid mapping nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) nsSaslMapBaseDNTemplate: dc=\2,dc=\3 nsSaslMapFilterTemplate: (uid=\1) # Name Only, mapping, sasl, config dn: cn=Name Only,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: ^[^:@]+$ cn: Name Only nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) # rfc 2829 dn syntax, mapping, sasl, config dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 dn syntax nsSaslMapRegexString: ^dn:\(.*\) nsSaslMapBaseDNTemplate: \1 nsSaslMapFilterTemplate: (objectclass=*) # rfc 2829 u syntax, mapping, sasl, config dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 u syntax nsSaslMapRegexString: ^u:\(.*\) nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (uid=\1) # uid mapping, mapping, sasl, config dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: uid mapping nsSaslMapRegexString: ^[^:@]+$ nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (uid=&) # search result search: 2 result: 0 Success # numResponses: 8 # numEntries: 7 [root at comipa02 ~]# -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 10, 2015 11:52 AM To: Gronde, Christopher (Contractor) ; Ludwig Krispenz ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. > > ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' > > > # search result > search: 2 > result: 0 Success > > # numResponses: 142 > # numEntries: 141 Right, we need to see the sasl mapping: $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, November 10, 2015 11:37 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > what do you get if you search for "objectclass=krbprincipal" ? > > On 11/10/2015 05:27 PM, Rich Megginson wrote: >> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>> Neither came back with anything >>> >>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 1 >>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP >>> Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (uid=ldap/*.gov) # requesting: uid # >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 1 >> >> That means this server has no LDAP service principals? I'm not sure >> how to recover IPA from this scenario. >> >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>> Megginson >>> Sent: Tuesday, November 10, 2015 11:04 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>> Thank you! I should have caught that... >>>> >>>> I changed the log level and then restarted dirsrv and attempted to >>>> start krb5kdc and got the following... >>> >>> >>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>> 172.16.100.208 to 172.16.100.161 >>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=1, SASL bind in progress >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>> base="dc=itmodev,dc=gov" scope=2 >>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >>> nentries=0 etime=0 >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>> nentries=0 >>> etime=0 >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>> >>> >>> >>> This is the SASL bind. It thinks the principal in the Kerberos >>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>> err=0 >>> tag=48 nentries=0. nentries=0 means no entries matched the search >>> criteria. >>> >>> You can do the search yourself with ldapsearch: >>> >>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>> >>> If you want to find out if there is some other ldap principal, do a >>> search like this: >>> >>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>> >>>>> Ran into an error trying to set that >>>>> >>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>> dn: cn=config >>>>> changetype: modify >>>>> replace: nsslapd-acesslog-level >>>>> : 260 >>>>> >>>>> modifying entry "cn=config" >>>>> ldap_modify: Server is unwilling to perform (53) >>>>> additional info: Unknown attribute >>>>> nsslapd-acesslog-level will be ignored >>>>> >>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>> Password: >>>>> ldap_bind: Inappropriate authentication (48) >>>>> >>>>> -----Original Message----- >>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> >>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>> ldapmodify? >>>>> yes, >>>>> ldapmodify ... >>>>> dn: cn=config >>>>> changetype: modify >>>>> replace: nsslapd-acesslog-level >>>>> nsslapd-acesslog-level: 260 >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com >>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>> Krispenz >>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> >>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>> Is it my LDAP password? >>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>> from to >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>> method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>> err=49 could also be a result if the entry which is mapped from >>>>>> the principal is not found in the directory. A bit more info >>>>>> could be gained by enabling logging of internal searches. >>>>>> Set nsslapd-acesslog-level: 260 >>>>>> >>>>>> and then look what internal searches are done during the gssapi >>>>>> authentication >>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>> means master and replica KDCs have different understanding of >>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>> >>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>> actually work but at least it allows to see if we are indeed >>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: Rob Crittenden ; >>>>>>>> freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> When I tried to start the service again I got no response from >>>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>>> access log >>>>>>>>> >>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>> from >>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>> from to >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>> method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>> method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>> method=sasl >>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>> nentries=0 etime=0 >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>> >>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>> >>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>> incorrect. >>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>> ticket for own service >>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>> Kerberos KDC is down. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> ; Alexander Bokovoy >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>> >>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>> what, if any, results were returned >>>>>>>>> >>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>> is what the error log shows >>>>>>>>>>> >>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>> signaling operation threads >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>>> down internal subsystems and plugins >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>> threads to stop >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>> stopped >>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>> Ok, that's good. >>>>>>>>>> >>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>> >>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>> >>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>> master key). >>>>>>>>>> >>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>> >>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>> data you do >>>>>>>>>> have: >>>>>>>>>> >>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>> >>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>> >>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>> >>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> Hello all! >>>>>>>>>>>> >>>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>>> >>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>>> [FAILED] >>>>>>>>>>>> >>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>> >>>>>>>>>>>> I found this article online: >>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sht >>>>>>>>>>>> m >>>>>>>>>>>> l >>>>>>>>>>>> >>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>> Tried the command >>>>>>>>>>>> listed: >>>>>>>>>>>> >>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>> >>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>> >>>>>>>>>>>> Any thoughts? >>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>> please. >>>>>>>>>>> >>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>>> anything else do not apply here at all. >>>>>>>>>>> >>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> -- >>>>>>>> / 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 > > From mbabinsk at redhat.com Tue Nov 10 17:02:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 18:02:58 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> Message-ID: <56422342.2050600@redhat.com> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: > # ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mapping, sasl, config > dn: cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsContainer > cn: mapping > > # Full Principal, mapping, sasl, config > dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: \(.*\)@\(.*\) > cn: Full Principal > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) > > # Kerberos uid mapping, mapping, sasl, config > dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: Kerberos uid mapping > nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) > nsSaslMapBaseDNTemplate: dc=\2,dc=\3 > nsSaslMapFilterTemplate: (uid=\1) Looks like this mapping rule causes the issues with incorrectly mapped service principals. > > # Name Only, mapping, sasl, config > dn: cn=Name Only,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: ^[^:@]+$ > cn: Name Only > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) > > # rfc 2829 dn syntax, mapping, sasl, config > dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 dn syntax > nsSaslMapRegexString: ^dn:\(.*\) > nsSaslMapBaseDNTemplate: \1 > nsSaslMapFilterTemplate: (objectclass=*) > > # rfc 2829 u syntax, mapping, sasl, config > dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 u syntax > nsSaslMapRegexString: ^u:\(.*\) > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=\1) > > # uid mapping, mapping, sasl, config > dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: uid mapping > nsSaslMapRegexString: ^[^:@]+$ > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=&) > > # search result > search: 2 > result: 0 Success > > # numResponses: 8 > # numEntries: 7 > [root at comipa02 ~]# > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, November 10, 2015 11:52 AM > To: Gronde, Christopher (Contractor) ; Ludwig Krispenz ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > Gronde, Christopher (Contractor) wrote: >> This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >> >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 142 >> # numEntries: 141 > > Right, we need to see the sasl mapping: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config > > rob > >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz >> Sent: Tuesday, November 10, 2015 11:37 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> what do you get if you search for "objectclass=krbprincipal" ? >> >> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>> Neither came back with anything >>>> >>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> Enter LDAP Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP >>>> Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/*.gov) # requesting: uid # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>> >>> That means this server has no LDAP service principals? I'm not sure >>> how to recover IPA from this scenario. >>> >>>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>> Megginson >>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>> Thank you! I should have caught that... >>>>> >>>>> I changed the log level and then restarted dirsrv and attempted to >>>>> start krb5kdc and got the following... >>>> >>>> >>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>> 172.16.100.208 to 172.16.100.161 >>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=1, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>> base="dc=itmodev,dc=gov" scope=2 >>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >>>> nentries=0 etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>> nentries=0 >>>> etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>> >>>> >>>> >>>> This is the SASL bind. It thinks the principal in the Kerberos >>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>> err=0 >>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>> criteria. >>>> >>>> You can do the search yourself with ldapsearch: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> >>>> If you want to find out if there is some other ldap principal, do a >>>> search like this: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>> >>>>>> Ran into an error trying to set that >>>>>> >>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> : 260 >>>>>> >>>>>> modifying entry "cn=config" >>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>> additional info: Unknown attribute >>>>>> nsslapd-acesslog-level will be ignored >>>>>> >>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>> Password: >>>>>> ldap_bind: Inappropriate authentication (48) >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> >>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>> ldapmodify? >>>>>> yes, >>>>>> ldapmodify ... >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> nsslapd-acesslog-level: 260 >>>>>>> -----Original Message----- >>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>> Krispenz >>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>> To: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> >>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>>> Is it my LDAP password? >>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>> the principal is not found in the directory. A bit more info >>>>>>> could be gained by enabling logging of internal searches. >>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>> >>>>>>> and then look what internal searches are done during the gssapi >>>>>>> authentication >>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>> means master and replica KDCs have different understanding of >>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>>> >>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>> freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> When I tried to start the service again I got no response from >>>>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>>>> access log >>>>>>>>>> >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>> from >>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>> nentries=0 etime=0 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>> >>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>> >>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>> incorrect. >>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>> ticket for own service >>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>> Kerberos KDC is down. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>> >>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>> what, if any, results were returned >>>>>>>>>> >>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>> authentication error) >>>>>>>>>>> >>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>> is what the error log shows >>>>>>>>>>>> >>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>> signaling operation threads >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>>>> down internal subsystems and plugins >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>> threads to stop >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>> stopped >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>> Ok, that's good. >>>>>>>>>>> >>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>> master key). >>>>>>>>>>> >>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>> >>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>> data you do >>>>>>>>>>> have: >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>> >>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> Hello all! >>>>>>>>>>>>> >>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>>>> >>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>>>> [FAILED] >>>>>>>>>>>>> >>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> >>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sht >>>>>>>>>>>>> m >>>>>>>>>>>>> l >>>>>>>>>>>>> >>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>>> Tried the command >>>>>>>>>>>>> listed: >>>>>>>>>>>>> >>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>> >>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>> >>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>> please. >>>>>>>>>>>> >>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>>>> anything else do not apply here at all. >>>>>>>>>>>> >>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> / 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 >> >> > > > -- Martin^3 Babinsky From Christopher.Gronde at fincen.gov Tue Nov 10 17:08:00 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 17:08:00 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56422342.2050600@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfincen.gov> >> # Kerberos uid mapping, mapping, sasl, config >> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> cn: Kerberos uid mapping >> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >> nsSaslMapFilterTemplate: (uid=\1) >Looks like this mapping rule causes the issues with incorrectly mapped service principals. Any idea what I need to do to fix it? -----Original Message----- From: Martin Babinsky [mailto:mbabinsk at redhat.com] Sent: Tuesday, November 10, 2015 12:03 PM To: Gronde, Christopher (Contractor) ; Rob Crittenden ; Ludwig Krispenz ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: > # ldapsearch -x -D 'cn=Directory Manager' -W -b > cn=mapping,cn=sasl,cn=config Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree # filter: > (objectclass=*) # requesting: ALL # > > # mapping, sasl, config > dn: cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsContainer > cn: mapping > > # Full Principal, mapping, sasl, config > dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: \(.*\)@\(.*\) > cn: Full Principal > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) > > # Kerberos uid mapping, mapping, sasl, config > dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: Kerberos uid mapping > nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) > nsSaslMapBaseDNTemplate: dc=\2,dc=\3 > nsSaslMapFilterTemplate: (uid=\1) Looks like this mapping rule causes the issues with incorrectly mapped service principals. > > # Name Only, mapping, sasl, config > dn: cn=Name Only,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: ^[^:@]+$ > cn: Name Only > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) > > # rfc 2829 dn syntax, mapping, sasl, config > dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 dn syntax > nsSaslMapRegexString: ^dn:\(.*\) > nsSaslMapBaseDNTemplate: \1 > nsSaslMapFilterTemplate: (objectclass=*) > > # rfc 2829 u syntax, mapping, sasl, config > dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 u syntax > nsSaslMapRegexString: ^u:\(.*\) > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=\1) > > # uid mapping, mapping, sasl, config > dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: uid mapping > nsSaslMapRegexString: ^[^:@]+$ > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=&) > > # search result > search: 2 > result: 0 Success > > # numResponses: 8 > # numEntries: 7 > [root at comipa02 ~]# > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, November 10, 2015 11:52 AM > To: Gronde, Christopher (Contractor) ; > Ludwig Krispenz ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos > authentication error) > > Gronde, Christopher (Contractor) wrote: >> This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >> >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 142 >> # numEntries: 141 > > Right, we need to see the sasl mapping: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b > cn=mapping,cn=sasl,cn=config > > rob > >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >> Krispenz >> Sent: Tuesday, November 10, 2015 11:37 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> what do you get if you search for "objectclass=krbprincipal" ? >> >> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>> Neither came back with anything >>>> >>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> Enter LDAP Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter >>>> LDAP >>>> Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/*.gov) # requesting: uid # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>> >>> That means this server has no LDAP service principals? I'm not sure >>> how to recover IPA from this scenario. >>> >>>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>> Megginson >>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>> Thank you! I should have caught that... >>>>> >>>>> I changed the log level and then restarted dirsrv and attempted to >>>>> start krb5kdc and got the following... >>>> >>>> >>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>> 172.16.100.208 to 172.16.100.161 >>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=1, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>> base="dc=itmodev,dc=gov" scope=2 >>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>> tag=48 >>>> nentries=0 etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>> nentries=0 >>>> etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>> >>>> >>>> >>>> This is the SASL bind. It thinks the principal in the Kerberos >>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>> err=0 >>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>> criteria. >>>> >>>> You can do the search yourself with ldapsearch: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> >>>> If you want to find out if there is some other ldap principal, do a >>>> search like this: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>> >>>>>> Ran into an error trying to set that >>>>>> >>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> : 260 >>>>>> >>>>>> modifying entry "cn=config" >>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>> additional info: Unknown attribute >>>>>> nsslapd-acesslog-level will be ignored >>>>>> >>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>> Password: >>>>>> ldap_bind: Inappropriate authentication (48) >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> >>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>> ldapmodify? >>>>>> yes, >>>>>> ldapmodify ... >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> nsslapd-acesslog-level: 260 >>>>>>> -----Original Message----- >>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>> Krispenz >>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>> To: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> >>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>>> Is it my LDAP password? >>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>> the principal is not found in the directory. A bit more info >>>>>>> could be gained by enabling logging of internal searches. >>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>> >>>>>>> and then look what internal searches are done during the gssapi >>>>>>> authentication >>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>> means master and replica KDCs have different understanding of >>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>>> >>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>> freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>> from tail of the log, but this is a repeating entry I see in >>>>>>>>>> the access log >>>>>>>>>> >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>> from >>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>> nentries=0 etime=0 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>> >>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>> >>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>> incorrect. >>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>> ticket for own service >>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>> Kerberos KDC is down. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>> >>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>> what, if any, results were returned >>>>>>>>>> >>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>> >>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>> is what the error log shows >>>>>>>>>>>> >>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>> signaling operation threads >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>> threads to stop >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>> stopped >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>> Ok, that's good. >>>>>>>>>>> >>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>> master key). >>>>>>>>>>> >>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>> >>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>> data you do >>>>>>>>>>> have: >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>> >>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> Hello all! >>>>>>>>>>>>> >>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>> >>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>> >>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> >>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sh >>>>>>>>>>>>> t >>>>>>>>>>>>> m >>>>>>>>>>>>> l >>>>>>>>>>>>> >>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>>> Tried the command >>>>>>>>>>>>> listed: >>>>>>>>>>>>> >>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>> >>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>> >>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>> please. >>>>>>>>>>>> >>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>> >>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> / 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 >> >> > > > -- Martin^3 Babinsky From natxo.asenjo at gmail.com Tue Nov 10 17:14:56 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 10 Nov 2015 18:14:56 +0100 Subject: [Freeipa-users] crl url redirecting to https In-Reply-To: <5642152A.3030204@redhat.com> References: <5642152A.3030204@redhat.com> Message-ID: hi, On Tue, Nov 10, 2015 at 5:02 PM, Rob Crittenden wrote: > Natxo Asenjo wrote:> Any ideas on how to fix this? > > You should have a sections like these in /etc/httpd/conf.d/ipa.conf: > > > SetHandler None > > ... > # For CRL publishing > Alias /ipa/crl "/var/lib/ipa/pki-ca/publish" > > SetHandler None > AllowOverride None > Options Indexes FollowSymLinks > Satisfy Any > Allow from all > > yes, it's all there. I restarted httpd just in case, but it remains the same. I get a 301 moved permantently to https. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Tue Nov 10 17:25:39 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 18:25:39 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> Message-ID: <56422893.9070703@redhat.com> On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote: >>> # Kerberos uid mapping, mapping, sasl, config >>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: Kerberos uid mapping >>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>> nsSaslMapFilterTemplate: (uid=\1) >> Looks like this mapping rule causes the issues with incorrectly mapped service principals. > Any idea what I need to do to fix it? I don't know where this mapping comes from and if it is needed, so one try would be to delete it. Another attempt would be to change the order of the mappings, but this would mean to rename them > > -----Original Message----- > From: Martin Babinsky [mailto:mbabinsk at redhat.com] > Sent: Tuesday, November 10, 2015 12:03 PM > To: Gronde, Christopher (Contractor) ; Rob Crittenden ; Ludwig Krispenz ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: >> # ldapsearch -x -D 'cn=Directory Manager' -W -b >> cn=mapping,cn=sasl,cn=config Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # filter: >> (objectclass=*) # requesting: ALL # >> >> # mapping, sasl, config >> dn: cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsContainer >> cn: mapping >> >> # Full Principal, mapping, sasl, config >> dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> nsSaslMapRegexString: \(.*\)@\(.*\) >> cn: Full Principal >> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >> nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) >> >> # Kerberos uid mapping, mapping, sasl, config >> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> cn: Kerberos uid mapping >> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >> nsSaslMapFilterTemplate: (uid=\1) > Looks like this mapping rule causes the issues with incorrectly mapped service principals. > >> # Name Only, mapping, sasl, config >> dn: cn=Name Only,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> nsSaslMapRegexString: ^[^:@]+$ >> cn: Name Only >> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >> nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) >> >> # rfc 2829 dn syntax, mapping, sasl, config >> dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> cn: rfc 2829 dn syntax >> nsSaslMapRegexString: ^dn:\(.*\) >> nsSaslMapBaseDNTemplate: \1 >> nsSaslMapFilterTemplate: (objectclass=*) >> >> # rfc 2829 u syntax, mapping, sasl, config >> dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> cn: rfc 2829 u syntax >> nsSaslMapRegexString: ^u:\(.*\) >> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >> nsSaslMapFilterTemplate: (uid=\1) >> >> # uid mapping, mapping, sasl, config >> dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config >> objectClass: top >> objectClass: nsSaslMapping >> cn: uid mapping >> nsSaslMapRegexString: ^[^:@]+$ >> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >> nsSaslMapFilterTemplate: (uid=&) >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 8 >> # numEntries: 7 >> [root at comipa02 ~]# >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Tuesday, November 10, 2015 11:52 AM >> To: Gronde, Christopher (Contractor) ; >> Ludwig Krispenz ; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> Gronde, Christopher (Contractor) wrote: >>> This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. >>> >>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >>> >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 142 >>> # numEntries: 141 >> Right, we need to see the sasl mapping: >> >> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >> cn=mapping,cn=sasl,cn=config >> >> rob >> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>> Krispenz >>> Sent: Tuesday, November 10, 2015 11:37 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> what do you get if you search for "objectclass=krbprincipal" ? >>> >>> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>>> Neither came back with anything >>>>> >>>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>> Enter LDAP Password: >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base with scope subtree # filter: >>>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>>> >>>>> # search result >>>>> search: 2 >>>>> result: 0 Success >>>>> >>>>> # numResponses: 1 >>>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter >>>>> LDAP >>>>> Password: >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base with scope subtree # filter: >>>>> (uid=ldap/*.gov) # requesting: uid # >>>>> >>>>> # search result >>>>> search: 2 >>>>> result: 0 Success >>>>> >>>>> # numResponses: 1 >>>> That means this server has no LDAP service principals? I'm not sure >>>> how to recover IPA from this scenario. >>>> >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>>> Megginson >>>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>>> Thank you! I should have caught that... >>>>>> >>>>>> I changed the log level and then restarted dirsrv and attempted to >>>>>> start krb5kdc and got the following... >>>>> >>>>> >>>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>>> 172.16.100.208 to 172.16.100.161 >>>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>>> nentries=0 etime=1, SASL bind in progress >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>>> nentries=0 etime=0, SASL bind in progress >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>>> version=3 mech=GSSAPI >>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>>> base="dc=itmodev,dc=gov" scope=2 >>>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>>> tag=48 >>>>> nentries=0 etime=0 >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>>> nentries=0 >>>>> etime=0 >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>>> >>>>> >>>>> >>>>> This is the SASL bind. It thinks the principal in the Kerberos >>>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>>> err=0 >>>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>>> criteria. >>>>> >>>>> You can do the search yourself with ldapsearch: >>>>> >>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>> >>>>> If you want to find out if there is some other ldap principal, do a >>>>> search like this: >>>>> >>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>>> >>>>>>> Ran into an error trying to set that >>>>>>> >>>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>>> dn: cn=config >>>>>>> changetype: modify >>>>>>> replace: nsslapd-acesslog-level >>>>>>> : 260 >>>>>>> >>>>>>> modifying entry "cn=config" >>>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>>> additional info: Unknown attribute >>>>>>> nsslapd-acesslog-level will be ignored >>>>>>> >>>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>>> Password: >>>>>>> ldap_bind: Inappropriate authentication (48) >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>>> To: Gronde, Christopher (Contractor) >>>>>>> >>>>>>> Cc: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> >>>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>>> ldapmodify? >>>>>>> yes, >>>>>>> ldapmodify ... >>>>>>> dn: cn=config >>>>>>> changetype: modify >>>>>>> replace: nsslapd-acesslog-level >>>>>>> nsslapd-acesslog-level: 260 >>>>>>>> -----Original Message----- >>>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>>> Krispenz >>>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>>> To: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>>>> Is it my LDAP password? >>>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>> from to >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>> method=sasl >>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>>> the principal is not found in the directory. A bit more info >>>>>>>> could be gained by enabling logging of internal searches. >>>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>>> >>>>>>>> and then look what internal searches are done during the gssapi >>>>>>>> authentication >>>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>>> means master and replica KDCs have different understanding of >>>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>>>> >>>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> >>>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>>> freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>>> from tail of the log, but this is a repeating entry I see in >>>>>>>>>>> the access log >>>>>>>>>>> >>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>>> from >>>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>> from to >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>> method=sasl >>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>>> method=sasl >>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>>> method=sasl >>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>>> nentries=0 etime=0 >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>>> >>>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>>> >>>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>>> incorrect. >>>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>>> ticket for own service >>>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>>> Kerberos KDC is down. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>> authentication error) >>>>>>>>>>> >>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>>> >>>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>>> what, if any, results were returned >>>>>>>>>>> >>>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>>> is what the error log shows >>>>>>>>>>>>> >>>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>> signaling operation threads >>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>>> threads to stop >>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>>> stopped >>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>> Ok, that's good. >>>>>>>>>>>> >>>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>>> >>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>>> >>>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>>> master key). >>>>>>>>>>>> >>>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>>> >>>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>>> data you do >>>>>>>>>>>> have: >>>>>>>>>>>> >>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>>> >>>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>>> >>>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>> Hello all! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>>> >>>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>>> >>>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>> >>>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sh >>>>>>>>>>>>>> t >>>>>>>>>>>>>> m >>>>>>>>>>>>>> l >>>>>>>>>>>>>> >>>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>>>> Tried the command >>>>>>>>>>>>>> listed: >>>>>>>>>>>>>> >>>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>>> >>>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>>> please. >>>>>>>>>>>>> >>>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>>> >>>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / 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 >>> >>> >> >> > > -- > Martin^3 Babinsky > From natxo.asenjo at gmail.com Tue Nov 10 17:22:36 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 10 Nov 2015 18:22:36 +0100 Subject: [Freeipa-users] crl url redirecting to https In-Reply-To: References: <5642152A.3030204@redhat.com> Message-ID: but going back to ipa-rewrite.conf, these 2 seem contradictory: # Redirect to the fully-qualified hostname. Not redirecting to secure # port so configuration files can be retrieved without requiring SSL. RewriteCond %{HTTP_HOST} !^kdc01.unix.iriszorg.nl$ [NC] RewriteRule ^/ipa/(.*) http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301] # Redirect to the secure port if not displaying an error or retrieving # configuration. RewriteCond %{SERVER_PORT} !^443$ RewriteCond %{REQUEST_URI} !^/ipa/(errors|config) RewriteRule ^/ipa/(.*) https://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301,NC] so I modified RewriteCond %{REQUEST_URI} !^/ipa/(errors|config) with RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl) and now it works. Is this ok? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Nov 10 17:26:20 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 10:26:20 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <56422893.9070703@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> Message-ID: <564228BC.3070900@redhat.com> On 11/10/2015 10:25 AM, Ludwig Krispenz wrote: > > On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote: >>>> # Kerberos uid mapping, mapping, sasl, config >>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: Kerberos uid mapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>> nsSaslMapFilterTemplate: (uid=\1) >>> Looks like this mapping rule causes the issues with incorrectly >>> mapped service principals. >> Any idea what I need to do to fix it? > I don't know where this mapping comes from and if it is needed, so one > try would be to delete it. > Another attempt would be to change the order of the mappings, but this > would mean to rename them In the older code, the SASL mappings were applied in reverse alphabetical order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being applied first. I thought there had been changes to this, so that you could explicitly define the order in which the mappings were applied. >> >> -----Original Message----- >> From: Martin Babinsky [mailto:mbabinsk at redhat.com] >> Sent: Tuesday, November 10, 2015 12:03 PM >> To: Gronde, Christopher (Contractor) ; >> Rob Crittenden ; Ludwig Krispenz >> ; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: >>> # ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=mapping,cn=sasl,cn=config Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (objectclass=*) # requesting: ALL # >>> >>> # mapping, sasl, config >>> dn: cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsContainer >>> cn: mapping >>> >>> # Full Principal, mapping, sasl, config >>> dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> nsSaslMapRegexString: \(.*\)@\(.*\) >>> cn: Full Principal >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) >>> >>> # Kerberos uid mapping, mapping, sasl, config >>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: Kerberos uid mapping >>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>> nsSaslMapFilterTemplate: (uid=\1) >> Looks like this mapping rule causes the issues with incorrectly >> mapped service principals. >> >>> # Name Only, mapping, sasl, config >>> dn: cn=Name Only,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> nsSaslMapRegexString: ^[^:@]+$ >>> cn: Name Only >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) >>> >>> # rfc 2829 dn syntax, mapping, sasl, config >>> dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: rfc 2829 dn syntax >>> nsSaslMapRegexString: ^dn:\(.*\) >>> nsSaslMapBaseDNTemplate: \1 >>> nsSaslMapFilterTemplate: (objectclass=*) >>> >>> # rfc 2829 u syntax, mapping, sasl, config >>> dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: rfc 2829 u syntax >>> nsSaslMapRegexString: ^u:\(.*\) >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (uid=\1) >>> >>> # uid mapping, mapping, sasl, config >>> dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: uid mapping >>> nsSaslMapRegexString: ^[^:@]+$ >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (uid=&) >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 8 >>> # numEntries: 7 >>> [root at comipa02 ~]# >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Tuesday, November 10, 2015 11:52 AM >>> To: Gronde, Christopher (Contractor) ; >>> Ludwig Krispenz ; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> This gave me a huge return! Appears to be a long list of all the >>>> servers and applications whose users authenticate to the IPA servers. >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >>>> >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 142 >>>> # numEntries: 141 >>> Right, we need to see the sasl mapping: >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=mapping,cn=sasl,cn=config >>> >>> rob >>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>> Krispenz >>>> Sent: Tuesday, November 10, 2015 11:37 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> what do you get if you search for "objectclass=krbprincipal" ? >>>> >>>> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>>>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>>>> Neither came back with anything >>>>>> >>>>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>> Enter LDAP Password: >>>>>> # extended LDIF >>>>>> # >>>>>> # LDAPv3 >>>>>> # base with scope subtree # filter: >>>>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>>>> >>>>>> # search result >>>>>> search: 2 >>>>>> result: 0 Success >>>>>> >>>>>> # numResponses: 1 >>>>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter >>>>>> LDAP >>>>>> Password: >>>>>> # extended LDIF >>>>>> # >>>>>> # LDAPv3 >>>>>> # base with scope subtree # filter: >>>>>> (uid=ldap/*.gov) # requesting: uid # >>>>>> >>>>>> # search result >>>>>> search: 2 >>>>>> result: 0 Success >>>>>> >>>>>> # numResponses: 1 >>>>> That means this server has no LDAP service principals? I'm not sure >>>>> how to recover IPA from this scenario. >>>>> >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com >>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>>>> Megginson >>>>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>>>> Thank you! I should have caught that... >>>>>>> >>>>>>> I changed the log level and then restarted dirsrv and attempted to >>>>>>> start krb5kdc and got the following... >>>>>> >>>>>> >>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>>>> 172.16.100.208 to 172.16.100.161 >>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=1, SASL bind in progress >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>>>> base="dc=itmodev,dc=gov" scope=2 >>>>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>>>> tag=48 >>>>>> nentries=0 etime=0 >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>>>> nentries=0 >>>>>> etime=0 >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>>>> >>>>>> >>>>>> >>>>>> This is the SASL bind. It thinks the principal in the Kerberos >>>>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>>>> err=0 >>>>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>>>> criteria. >>>>>> >>>>>> You can do the search yourself with ldapsearch: >>>>>> >>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>> >>>>>> If you want to find out if there is some other ldap principal, do a >>>>>> search like this: >>>>>> >>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>>>> >>>>>>>> Ran into an error trying to set that >>>>>>>> >>>>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>>>> dn: cn=config >>>>>>>> changetype: modify >>>>>>>> replace: nsslapd-acesslog-level >>>>>>>> : 260 >>>>>>>> >>>>>>>> modifying entry "cn=config" >>>>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>>>> additional info: Unknown attribute >>>>>>>> nsslapd-acesslog-level will be ignored >>>>>>>> >>>>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>>>> Password: >>>>>>>> ldap_bind: Inappropriate authentication (48) >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>>>> ldapmodify? >>>>>>>> yes, >>>>>>>> ldapmodify ... >>>>>>>> dn: cn=config >>>>>>>> changetype: modify >>>>>>>> replace: nsslapd-acesslog-level >>>>>>>> nsslapd-acesslog-level: 260 >>>>>>>>> -----Original Message----- >>>>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>>>> Krispenz >>>>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>>>> To: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Where can I verify or change the credentials it is trying to >>>>>>>>>>> use? >>>>>>>>>>> Is it my LDAP password? >>>>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>>> from to >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>>>> the principal is not found in the directory. A bit more info >>>>>>>>> could be gained by enabling logging of internal searches. >>>>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>>>> >>>>>>>>> and then look what internal searches are done during the gssapi >>>>>>>>> authentication >>>>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>>>> means master and replica KDCs have different understanding of >>>>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>>>> means keys were rotated on master and weren't propagated to >>>>>>>>>> replica. >>>>>>>>>> >>>>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> >>>>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>>>> freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>> authentication error) >>>>>>>>>>> >>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>>>> from tail of the log, but this is a repeating entry I see in >>>>>>>>>>>> the access log >>>>>>>>>>>> >>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>>>> from >>>>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>>> from to >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>>>> nentries=0 etime=0 >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>>>> >>>>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>>>> >>>>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>>>> incorrect. >>>>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>>>> ticket for own service >>>>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>>>> Kerberos KDC is down. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>>> authentication error) >>>>>>>>>>>> >>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> Nothing bad came back and there is definitely data in the >>>>>>>>>>>>> tree. >>>>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>>>> >>>>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>>>> what, if any, results were returned >>>>>>>>>>>> >>>>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>> >>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>>>> is what the error log shows >>>>>>>>>>>>>> >>>>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>> signaling operation threads >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>>>> threads to stop >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>>>> stopped >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>>> Ok, that's good. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>>>> >>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>>>> >>>>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>>>> master key). >>>>>>>>>>>>> >>>>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>>>> >>>>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>>>> data you do >>>>>>>>>>>>> have: >>>>>>>>>>>>> >>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>>>> >>>>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>>>> >>>>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>>> Hello all! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sh >>>>>>>>>>>>>>> t >>>>>>>>>>>>>>> m >>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create >>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>> Tried the command >>>>>>>>>>>>>>> listed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>>>> please. >>>>>>>>>>>>>> >>>>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / 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 >>>> >>>> >>> >>> >> >> -- >> Martin^3 Babinsky >> > From Christopher.Gronde at fincen.gov Tue Nov 10 17:50:46 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 17:50:46 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <564228BC.3070900@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen.gov> Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Tuesday, November 10, 2015 12:26 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) On 11/10/2015 10:25 AM, Ludwig Krispenz wrote: > > On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote: >>>> # Kerberos uid mapping, mapping, sasl, config >>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: Kerberos uid mapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>> nsSaslMapFilterTemplate: (uid=\1) >>> Looks like this mapping rule causes the issues with incorrectly >>> mapped service principals. >> Any idea what I need to do to fix it? > I don't know where this mapping comes from and if it is needed, so one > try would be to delete it. > Another attempt would be to change the order of the mappings, but this > would mean to rename them In the older code, the SASL mappings were applied in reverse alphabetical order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being applied first. I thought there had been changes to this, so that you could explicitly define the order in which the mappings were applied. >> >> -----Original Message----- >> From: Martin Babinsky [mailto:mbabinsk at redhat.com] >> Sent: Tuesday, November 10, 2015 12:03 PM >> To: Gronde, Christopher (Contractor) ; >> Rob Crittenden ; Ludwig Krispenz >> ; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: >>> # ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=mapping,cn=sasl,cn=config Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree # filter: >>> (objectclass=*) # requesting: ALL # >>> >>> # mapping, sasl, config >>> dn: cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsContainer >>> cn: mapping >>> >>> # Full Principal, mapping, sasl, config >>> dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> nsSaslMapRegexString: \(.*\)@\(.*\) >>> cn: Full Principal >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) >>> >>> # Kerberos uid mapping, mapping, sasl, config >>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: Kerberos uid mapping >>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>> nsSaslMapFilterTemplate: (uid=\1) >> Looks like this mapping rule causes the issues with incorrectly >> mapped service principals. >> >>> # Name Only, mapping, sasl, config >>> dn: cn=Name Only,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> nsSaslMapRegexString: ^[^:@]+$ >>> cn: Name Only >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) >>> >>> # rfc 2829 dn syntax, mapping, sasl, config >>> dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: rfc 2829 dn syntax >>> nsSaslMapRegexString: ^dn:\(.*\) >>> nsSaslMapBaseDNTemplate: \1 >>> nsSaslMapFilterTemplate: (objectclass=*) >>> >>> # rfc 2829 u syntax, mapping, sasl, config >>> dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: rfc 2829 u syntax >>> nsSaslMapRegexString: ^u:\(.*\) >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (uid=\1) >>> >>> # uid mapping, mapping, sasl, config >>> dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config >>> objectClass: top >>> objectClass: nsSaslMapping >>> cn: uid mapping >>> nsSaslMapRegexString: ^[^:@]+$ >>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>> nsSaslMapFilterTemplate: (uid=&) >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 8 >>> # numEntries: 7 >>> [root at comipa02 ~]# >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Tuesday, November 10, 2015 11:52 AM >>> To: Gronde, Christopher (Contractor) >>> ; Ludwig Krispenz >>> ; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> Gronde, Christopher (Contractor) wrote: >>>> This gave me a huge return! Appears to be a long list of all the >>>> servers and applications whose users authenticate to the IPA servers. >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >>>> >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 142 >>>> # numEntries: 141 >>> Right, we need to see the sasl mapping: >>> >>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>> cn=mapping,cn=sasl,cn=config >>> >>> rob >>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>> Krispenz >>>> Sent: Tuesday, November 10, 2015 11:37 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> what do you get if you search for "objectclass=krbprincipal" ? >>>> >>>> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>>>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>>>> Neither came back with anything >>>>>> >>>>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>> Enter LDAP Password: >>>>>> # extended LDIF >>>>>> # >>>>>> # LDAPv3 >>>>>> # base with scope subtree # filter: >>>>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>>>> >>>>>> # search result >>>>>> search: 2 >>>>>> result: 0 Success >>>>>> >>>>>> # numResponses: 1 >>>>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D >>>>>> "cn=directory manager" -W -b "dc=itmodev,dc=gov" >>>>>> '(uid=ldap/*.gov)' uid Enter LDAP >>>>>> Password: >>>>>> # extended LDIF >>>>>> # >>>>>> # LDAPv3 >>>>>> # base with scope subtree # filter: >>>>>> (uid=ldap/*.gov) # requesting: uid # >>>>>> >>>>>> # search result >>>>>> search: 2 >>>>>> result: 0 Success >>>>>> >>>>>> # numResponses: 1 >>>>> That means this server has no LDAP service principals? I'm not >>>>> sure how to recover IPA from this scenario. >>>>> >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com >>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>>>> Megginson >>>>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>>>> Thank you! I should have caught that... >>>>>>> >>>>>>> I changed the log level and then restarted dirsrv and attempted >>>>>>> to start krb5kdc and got the following... >>>>>> >>>>>> >>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>>>> 172.16.100.208 to 172.16.100.161 >>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>>>> nentries=0 etime=1, SASL bind in progress >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>>>> nentries=0 etime=0, SASL bind in progress >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>>>> version=3 mech=GSSAPI >>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>>>> base="dc=itmodev,dc=gov" scope=2 >>>>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>>>> tag=48 >>>>>> nentries=0 etime=0 >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>>>> nentries=0 >>>>>> etime=0 >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>>>> >>>>>> >>>>>> >>>>>> This is the SASL bind. It thinks the principal in the Kerberos >>>>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>>>> under dc=itmodev,dc=gov. However, this entry is not found: >>>>>> RESULT >>>>>> err=0 >>>>>> tag=48 nentries=0. nentries=0 means no entries matched the >>>>>> search criteria. >>>>>> >>>>>> You can do the search yourself with ldapsearch: >>>>>> >>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>> >>>>>> If you want to find out if there is some other ldap principal, do >>>>>> a search like this: >>>>>> >>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>>>> >>>>>>>> Ran into an error trying to set that >>>>>>>> >>>>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>>>> dn: cn=config >>>>>>>> changetype: modify >>>>>>>> replace: nsslapd-acesslog-level >>>>>>>> : 260 >>>>>>>> >>>>>>>> modifying entry "cn=config" >>>>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>>>> additional info: Unknown attribute >>>>>>>> nsslapd-acesslog-level will be ignored >>>>>>>> >>>>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>>>> Password: >>>>>>>> ldap_bind: Inappropriate authentication (48) >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>> >>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>> authentication error) >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>>>> ldapmodify? >>>>>>>> yes, >>>>>>>> ldapmodify ... >>>>>>>> dn: cn=config >>>>>>>> changetype: modify >>>>>>>> replace: nsslapd-acesslog-level >>>>>>>> nsslapd-acesslog-level: 260 >>>>>>>>> -----Original Message----- >>>>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>>>> Krispenz >>>>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>>>> To: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Where can I verify or change the credentials it is trying to >>>>>>>>>>> use? >>>>>>>>>>> Is it my LDAP password? >>>>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 >>>>>>>>>>>> connection from to >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>> err=49 could also be a result if the entry which is mapped >>>>>>>>> from the principal is not found in the directory. A bit more >>>>>>>>> info could be gained by enabling logging of internal searches. >>>>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>>>> >>>>>>>>> and then look what internal searches are done during the >>>>>>>>> gssapi authentication >>>>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>>>> talking to ldap/ Kerberos principal. If that fails, >>>>>>>>>> it means master and replica KDCs have different understanding >>>>>>>>>> of both ldap/ and ldap/ keys which most >>>>>>>>>> likely means keys were rotated on master and weren't >>>>>>>>>> propagated to replica. >>>>>>>>>> >>>>>>>>>> How to solve it? One possibility is to set master's hostname >>>>>>>>>> as KDC address in krb5.conf on replica, forcing LDAP server >>>>>>>>>> on replica to use master's KDC. I'm absolutely not sure this >>>>>>>>>> will actually work but at least it allows to see if we are >>>>>>>>>> indeed dealing with inconsistent state of service principals' keys. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> >>>>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>>>> freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>> >>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>>>> from tail of the log, but this is a repeating entry I see >>>>>>>>>>>> in the access log >>>>>>>>>>>> >>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 >>>>>>>>>>>> connection from >>>>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 >>>>>>>>>>>> connection from to >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 >>>>>>>>>>>> tag=97 >>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 >>>>>>>>>>>> tag=97 >>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>>>> method=sasl >>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 >>>>>>>>>>>> tag=97 >>>>>>>>>>>> nentries=0 etime=0 >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>>>> >>>>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>>>> >>>>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>>>> incorrect. >>>>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>>>> ticket for own service >>>>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>>>> Kerberos KDC is down. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> Nothing bad came back and there is definitely data in the >>>>>>>>>>>>> tree. >>>>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch >>>>>>>>>>>> the 389-ds access log (buffered) to: >>>>>>>>>>>> >>>>>>>>>>>> 1. See if it is binding at all 2. See what the search is >>>>>>>>>>>> and what, if any, results were returned >>>>>>>>>>>> >>>>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>> >>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and >>>>>>>>>>>>>> this is what the error log shows >>>>>>>>>>>>>> >>>>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening >>>>>>>>>>>>>> on All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>> signaling operation threads >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>>>> threads to stop >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>>>> stopped >>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening >>>>>>>>>>>>>> on All Interfaces port 389 for LDAP requests >>>>>>>>>>>>> Ok, that's good. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>>>> >>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>>>> >>>>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>>>> master key). >>>>>>>>>>>>> >>>>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>>>> >>>>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see >>>>>>>>>>>>> what data you do >>>>>>>>>>>>> have: >>>>>>>>>>>>> >>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>>>> >>>>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>>>> >>>>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>>> Hello all! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize >>>>>>>>>>>>>>> realm ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos. >>>>>>>>>>>>>>> sh >>>>>>>>>>>>>>> t >>>>>>>>>>>>>>> m >>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create >>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>> Tried the command >>>>>>>>>>>>>>> listed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No further information found on the proceeding error >>>>>>>>>>>>>>> above for the kdb5_util command. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>>> First: don't use instructions which are not related to >>>>>>>>>>>>>> IPA, please. >>>>>>>>>>>>>> >>>>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you see 'Server error - while fetching master key ..' >>>>>>>>>>>>>> it means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>>>> Does LDAP server work on the replica? What is in its >>>>>>>>>>>>>> error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / 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 >>>> >>>> >>> >>> >> >> -- >> 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 From lkrispen at redhat.com Tue Nov 10 17:56:38 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 10 Nov 2015 18:56:38 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <564228BC.3070900@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> Message-ID: <56422FD6.1000900@redhat.com> On 11/10/2015 06:26 PM, Rich Megginson wrote: > On 11/10/2015 10:25 AM, Ludwig Krispenz wrote: >> >> On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote: >>>>> # Kerberos uid mapping, mapping, sasl, config >>>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>>> objectClass: top >>>>> objectClass: nsSaslMapping >>>>> cn: Kerberos uid mapping >>>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>>> nsSaslMapFilterTemplate: (uid=\1) >>>> Looks like this mapping rule causes the issues with incorrectly >>>> mapped service principals. >>> Any idea what I need to do to fix it? >> I don't know where this mapping comes from and if it is needed, so >> one try would be to delete it. >> Another attempt would be to change the order of the mappings, but >> this would mean to rename them > > In the older code, the SASL mappings were applied in reverse > alphabetical order, which is why cn=uid > mapping,cn=mapping,cn=sasl,cn=config is being applied first. I > thought there had been changes to this, so that you could explicitly > define the order in which the mappings were applied. yes, there is a saslmapPriority, but this is 1.2.11, don't know what you mean by Old :-) > >>> >>> -----Original Message----- >>> From: Martin Babinsky [mailto:mbabinsk at redhat.com] >>> Sent: Tuesday, November 10, 2015 12:03 PM >>> To: Gronde, Christopher (Contractor) >>> ; Rob Crittenden >>> ; Ludwig Krispenz ; >>> freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: >>>> # ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=mapping,cn=sasl,cn=config Enter LDAP Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (objectclass=*) # requesting: ALL # >>>> >>>> # mapping, sasl, config >>>> dn: cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsContainer >>>> cn: mapping >>>> >>>> # Full Principal, mapping, sasl, config >>>> dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\) >>>> cn: Full Principal >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) >>>> >>>> # Kerberos uid mapping, mapping, sasl, config >>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: Kerberos uid mapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>> nsSaslMapFilterTemplate: (uid=\1) >>> Looks like this mapping rule causes the issues with incorrectly >>> mapped service principals. >>> >>>> # Name Only, mapping, sasl, config >>>> dn: cn=Name Only,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> nsSaslMapRegexString: ^[^:@]+$ >>>> cn: Name Only >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) >>>> >>>> # rfc 2829 dn syntax, mapping, sasl, config >>>> dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: rfc 2829 dn syntax >>>> nsSaslMapRegexString: ^dn:\(.*\) >>>> nsSaslMapBaseDNTemplate: \1 >>>> nsSaslMapFilterTemplate: (objectclass=*) >>>> >>>> # rfc 2829 u syntax, mapping, sasl, config >>>> dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: rfc 2829 u syntax >>>> nsSaslMapRegexString: ^u:\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (uid=\1) >>>> >>>> # uid mapping, mapping, sasl, config >>>> dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: uid mapping >>>> nsSaslMapRegexString: ^[^:@]+$ >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (uid=&) >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 8 >>>> # numEntries: 7 >>>> [root at comipa02 ~]# >>>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Tuesday, November 10, 2015 11:52 AM >>>> To: Gronde, Christopher (Contractor) ; >>>> Ludwig Krispenz ; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> This gave me a huge return! Appears to be a long list of all the >>>>> servers and applications whose users authenticate to the IPA servers. >>>>> >>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>> "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >>>>> >>>>> >>>>> # search result >>>>> search: 2 >>>>> result: 0 Success >>>>> >>>>> # numResponses: 142 >>>>> # numEntries: 141 >>>> Right, we need to see the sasl mapping: >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=mapping,cn=sasl,cn=config >>>> >>>> rob >>>> >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 11:37 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> what do you get if you search for "objectclass=krbprincipal" ? >>>>> >>>>> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>>>>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>>>>> Neither came back with anything >>>>>>> >>>>>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>>> Enter LDAP Password: >>>>>>> # extended LDIF >>>>>>> # >>>>>>> # LDAPv3 >>>>>>> # base with scope subtree # filter: >>>>>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>>>>> >>>>>>> # search result >>>>>>> search: 2 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # numResponses: 1 >>>>>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>>>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter >>>>>>> LDAP >>>>>>> Password: >>>>>>> # extended LDIF >>>>>>> # >>>>>>> # LDAPv3 >>>>>>> # base with scope subtree # filter: >>>>>>> (uid=ldap/*.gov) # requesting: uid # >>>>>>> >>>>>>> # search result >>>>>>> search: 2 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # numResponses: 1 >>>>>> That means this server has no LDAP service principals? I'm not sure >>>>>> how to recover IPA from this scenario. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>>>>> Megginson >>>>>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>>>>> To: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>>>>> Thank you! I should have caught that... >>>>>>>> >>>>>>>> I changed the log level and then restarted dirsrv and attempted to >>>>>>>> start krb5kdc and got the following... >>>>>>> >>>>>>> >>>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>>>>> 172.16.100.208 to 172.16.100.161 >>>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=1, SASL bind in progress >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>>>>> base="dc=itmodev,dc=gov" scope=2 >>>>>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>>>>> tag=48 >>>>>>> nentries=0 etime=0 >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>>>>> nentries=0 >>>>>>> etime=0 >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is the SASL bind. It thinks the principal in the Kerberos >>>>>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>>>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>>>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>>>>> err=0 >>>>>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>>>>> criteria. >>>>>>> >>>>>>> You can do the search yourself with ldapsearch: >>>>>>> >>>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>>> >>>>>>> If you want to find out if there is some other ldap principal, do a >>>>>>> search like this: >>>>>>> >>>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>>>>> >>>>>>>>> Ran into an error trying to set that >>>>>>>>> >>>>>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>>>>> dn: cn=config >>>>>>>>> changetype: modify >>>>>>>>> replace: nsslapd-acesslog-level >>>>>>>>> : 260 >>>>>>>>> >>>>>>>>> modifying entry "cn=config" >>>>>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>>>>> additional info: Unknown attribute >>>>>>>>> nsslapd-acesslog-level will be ignored >>>>>>>>> >>>>>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>>>>> Password: >>>>>>>>> ldap_bind: Inappropriate authentication (48) >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>>>>> ldapmodify? >>>>>>>>> yes, >>>>>>>>> ldapmodify ... >>>>>>>>> dn: cn=config >>>>>>>>> changetype: modify >>>>>>>>> replace: nsslapd-acesslog-level >>>>>>>>> nsslapd-acesslog-level: 260 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>>>>> Krispenz >>>>>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>>>>> To: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> Where can I verify or change the credentials it is trying >>>>>>>>>>>> to use? >>>>>>>>>>>> Is it my LDAP password? >>>>>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>>>> from to >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>>>>> the principal is not found in the directory. A bit more info >>>>>>>>>> could be gained by enabling logging of internal searches. >>>>>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>>>>> >>>>>>>>>> and then look what internal searches are done during the gssapi >>>>>>>>>> authentication >>>>>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>>>>> means master and replica KDCs have different understanding of >>>>>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>>>>> means keys were rotated on master and weren't propagated to >>>>>>>>>>> replica. >>>>>>>>>>> >>>>>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> >>>>>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>>>>> freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>>> authentication error) >>>>>>>>>>>> >>>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>>>>> from tail of the log, but this is a repeating entry I see in >>>>>>>>>>>>> the access log >>>>>>>>>>>>> >>>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>>>>> from >>>>>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>>>>> from to >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>>>>> nentries=0 etime=0 >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>>>>> >>>>>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>>>>> >>>>>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>>>>> incorrect. >>>>>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>>>>> ticket for own service >>>>>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>>>>> Kerberos KDC is down. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>>>> authentication error) >>>>>>>>>>>>> >>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>> Nothing bad came back and there is definitely data in the >>>>>>>>>>>>>> tree. >>>>>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>>>>> what, if any, results were returned >>>>>>>>>>>>> >>>>>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>>>>> is what the error log shows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>>> signaling operation threads >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>>>>> threads to stop >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>>>>> stopped >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>> Ok, that's good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>>>>> >>>>>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>>>>> master key). >>>>>>>>>>>>>> >>>>>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>>>>> data you do >>>>>>>>>>>>>> have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>>>>> >>>>>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> rob >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Hello all! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>>>>> ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sh >>>>>>>>>>>>>>>> t >>>>>>>>>>>>>>>> m >>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create >>>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>>> Tried the command >>>>>>>>>>>>>>>> listed: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>>>>> please. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / 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 >>>>> >>>>> >>>> >>>> >>> >>> -- >>> Martin^3 Babinsky >>> >> > From rmeggins at redhat.com Tue Nov 10 17:59:46 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 10 Nov 2015 10:59:46 -0700 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen.gov> Message-ID: <56423092.10301@redhat.com> On 11/10/2015 10:50 AM, Gronde, Christopher (Contractor) wrote: > Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? http://www.port389.org/docs/389ds/design/sasl-mapping-improvements-1-dot-3-1.html However, looking at your version: https://www.redhat.com/archives/freeipa-users/2015-November/msg00124.html You are using EL6 389-ds-base 1.2.11.x, which does not support the above sasl mapping improvements. I have no idea how IPA is supposed to handle this situation with 389-ds-base 1.2.11. > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Tuesday, November 10, 2015 12:26 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > On 11/10/2015 10:25 AM, Ludwig Krispenz wrote: >> On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote: >>>>> # Kerberos uid mapping, mapping, sasl, config >>>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>>> objectClass: top >>>>> objectClass: nsSaslMapping >>>>> cn: Kerberos uid mapping >>>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>>> nsSaslMapFilterTemplate: (uid=\1) >>>> Looks like this mapping rule causes the issues with incorrectly >>>> mapped service principals. >>> Any idea what I need to do to fix it? >> I don't know where this mapping comes from and if it is needed, so one >> try would be to delete it. >> Another attempt would be to change the order of the mappings, but this >> would mean to rename them > In the older code, the SASL mappings were applied in reverse alphabetical order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being applied first. I thought there had been changes to this, so that you could explicitly define the order in which the mappings were applied. > >>> -----Original Message----- >>> From: Martin Babinsky [mailto:mbabinsk at redhat.com] >>> Sent: Tuesday, November 10, 2015 12:03 PM >>> To: Gronde, Christopher (Contractor) ; >>> Rob Crittenden ; Ludwig Krispenz >>> ; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>> authentication error) >>> >>> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote: >>>> # ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=mapping,cn=sasl,cn=config Enter LDAP Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (objectclass=*) # requesting: ALL # >>>> >>>> # mapping, sasl, config >>>> dn: cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsContainer >>>> cn: mapping >>>> >>>> # Full Principal, mapping, sasl, config >>>> dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\) >>>> cn: Full Principal >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) >>>> >>>> # Kerberos uid mapping, mapping, sasl, config >>>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: Kerberos uid mapping >>>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3 >>>> nsSaslMapFilterTemplate: (uid=\1) >>> Looks like this mapping rule causes the issues with incorrectly >>> mapped service principals. >>> >>>> # Name Only, mapping, sasl, config >>>> dn: cn=Name Only,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> nsSaslMapRegexString: ^[^:@]+$ >>>> cn: Name Only >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) >>>> >>>> # rfc 2829 dn syntax, mapping, sasl, config >>>> dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: rfc 2829 dn syntax >>>> nsSaslMapRegexString: ^dn:\(.*\) >>>> nsSaslMapBaseDNTemplate: \1 >>>> nsSaslMapFilterTemplate: (objectclass=*) >>>> >>>> # rfc 2829 u syntax, mapping, sasl, config >>>> dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: rfc 2829 u syntax >>>> nsSaslMapRegexString: ^u:\(.*\) >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (uid=\1) >>>> >>>> # uid mapping, mapping, sasl, config >>>> dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config >>>> objectClass: top >>>> objectClass: nsSaslMapping >>>> cn: uid mapping >>>> nsSaslMapRegexString: ^[^:@]+$ >>>> nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov >>>> nsSaslMapFilterTemplate: (uid=&) >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 8 >>>> # numEntries: 7 >>>> [root at comipa02 ~]# >>>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Tuesday, November 10, 2015 11:52 AM >>>> To: Gronde, Christopher (Contractor) >>>> ; Ludwig Krispenz >>>> ; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> Gronde, Christopher (Contractor) wrote: >>>>> This gave me a huge return! Appears to be a long list of all the >>>>> servers and applications whose users authenticate to the IPA servers. >>>>> >>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>> "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >>>>> >>>>> >>>>> # search result >>>>> search: 2 >>>>> result: 0 Success >>>>> >>>>> # numResponses: 142 >>>>> # numEntries: 141 >>>> Right, we need to see the sasl mapping: >>>> >>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>> cn=mapping,cn=sasl,cn=config >>>> >>>> rob >>>> >>>>> -----Original Message----- >>>>> From: freeipa-users-bounces at redhat.com >>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>> Krispenz >>>>> Sent: Tuesday, November 10, 2015 11:37 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>> authentication error) >>>>> >>>>> what do you get if you search for "objectclass=krbprincipal" ? >>>>> >>>>> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>>>>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>>>>> Neither came back with anything >>>>>>> >>>>>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>>> Enter LDAP Password: >>>>>>> # extended LDIF >>>>>>> # >>>>>>> # LDAPv3 >>>>>>> # base with scope subtree # filter: >>>>>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>>>>> >>>>>>> # search result >>>>>>> search: 2 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # numResponses: 1 >>>>>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D >>>>>>> "cn=directory manager" -W -b "dc=itmodev,dc=gov" >>>>>>> '(uid=ldap/*.gov)' uid Enter LDAP >>>>>>> Password: >>>>>>> # extended LDIF >>>>>>> # >>>>>>> # LDAPv3 >>>>>>> # base with scope subtree # filter: >>>>>>> (uid=ldap/*.gov) # requesting: uid # >>>>>>> >>>>>>> # search result >>>>>>> search: 2 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # numResponses: 1 >>>>>> That means this server has no LDAP service principals? I'm not >>>>>> sure how to recover IPA from this scenario. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>>>>> Megginson >>>>>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>>>>> To: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>>>>> Thank you! I should have caught that... >>>>>>>> >>>>>>>> I changed the log level and then restarted dirsrv and attempted >>>>>>>> to start krb5kdc and got the following... >>>>>>> >>>>>>> >>>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>>>>> 172.16.100.208 to 172.16.100.161 >>>>>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=1, SASL bind in progress >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>>>>> version=3 mech=GSSAPI >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>>>>> base="dc=itmodev,dc=gov" scope=2 >>>>>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 >>>>>>> tag=48 >>>>>>> nentries=0 etime=0 >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>>>>> nentries=0 >>>>>>> etime=0 >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>>>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is the SASL bind. It thinks the principal in the Kerberos >>>>>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>>>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>>>>> under dc=itmodev,dc=gov. However, this entry is not found: >>>>>>> RESULT >>>>>>> err=0 >>>>>>> tag=48 nentries=0. nentries=0 means no entries matched the >>>>>>> search criteria. >>>>>>> >>>>>>> You can do the search yourself with ldapsearch: >>>>>>> >>>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>>>>> >>>>>>> If you want to find out if there is some other ldap principal, do >>>>>>> a search like this: >>>>>>> >>>>>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>>>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>>>>> >>>>>>>>> Ran into an error trying to set that >>>>>>>>> >>>>>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>>>>> dn: cn=config >>>>>>>>> changetype: modify >>>>>>>>> replace: nsslapd-acesslog-level >>>>>>>>> : 260 >>>>>>>>> >>>>>>>>> modifying entry "cn=config" >>>>>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>>>>> additional info: Unknown attribute >>>>>>>>> nsslapd-acesslog-level will be ignored >>>>>>>>> >>>>>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>>>>> Password: >>>>>>>>> ldap_bind: Inappropriate authentication (48) >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>>>>> ldapmodify? >>>>>>>>> yes, >>>>>>>>> ldapmodify ... >>>>>>>>> dn: cn=config >>>>>>>>> changetype: modify >>>>>>>>> replace: nsslapd-acesslog-level >>>>>>>>> nsslapd-acesslog-level: 260 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>>>>> Krispenz >>>>>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>>>>> To: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> Where can I verify or change the credentials it is trying to >>>>>>>>>>>> use? >>>>>>>>>>>> Is it my LDAP password? >>>>>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 >>>>>>>>>>>>> connection from to >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> err=49 could also be a result if the entry which is mapped >>>>>>>>>> from the principal is not found in the directory. A bit more >>>>>>>>>> info could be gained by enabling logging of internal searches. >>>>>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>>>>> >>>>>>>>>> and then look what internal searches are done during the >>>>>>>>>> gssapi authentication >>>>>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>>>>> talking to ldap/ Kerberos principal. If that fails, >>>>>>>>>>> it means master and replica KDCs have different understanding >>>>>>>>>>> of both ldap/ and ldap/ keys which most >>>>>>>>>>> likely means keys were rotated on master and weren't >>>>>>>>>>> propagated to replica. >>>>>>>>>>> >>>>>>>>>>> How to solve it? One possibility is to set master's hostname >>>>>>>>>>> as KDC address in krb5.conf on replica, forcing LDAP server >>>>>>>>>>> on replica to use master's KDC. I'm absolutely not sure this >>>>>>>>>>> will actually work but at least it allows to see if we are >>>>>>>>>>> indeed dealing with inconsistent state of service principals' keys. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> >>>>>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>>>>> freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> When I tried to start the service again I got no response >>>>>>>>>>>>> from tail of the log, but this is a repeating entry I see >>>>>>>>>>>>> in the access log >>>>>>>>>>>>> >>>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 >>>>>>>>>>>>> connection from >>>>>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 >>>>>>>>>>>>> connection from to >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 >>>>>>>>>>>>> tag=97 >>>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 >>>>>>>>>>>>> tag=97 >>>>>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>>>>> method=sasl >>>>>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 >>>>>>>>>>>>> tag=97 >>>>>>>>>>>>> nentries=0 etime=0 >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>>>>> >>>>>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>>>>> >>>>>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>>>>> incorrect. >>>>>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>>>>> ticket for own service >>>>>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>>>>> Kerberos KDC is down. >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>> >>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>> Nothing bad came back and there is definitely data in the >>>>>>>>>>>>>> tree. >>>>>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch >>>>>>>>>>>>> the 389-ds access log (buffered) to: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. See if it is binding at all 2. See what the search is >>>>>>>>>>>>> and what, if any, results were returned >>>>>>>>>>>>> >>>>>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and >>>>>>>>>>>>>>> this is what the error log shows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening >>>>>>>>>>>>>>> on All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>>> signaling operation threads >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>>>>> closing down internal subsystems and plugins >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>>>>> threads to stop >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>>>>> stopped >>>>>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>>>>> recommend to increase the entry cache size >>>>>>>>>>>>>>> nsslapd-cachememsize. >>>>>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening >>>>>>>>>>>>>>> on All Interfaces port 389 for LDAP requests >>>>>>>>>>>>>> Ok, that's good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>>>>> >>>>>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>>>>> master key). >>>>>>>>>>>>>> >>>>>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see >>>>>>>>>>>>>> what data you do >>>>>>>>>>>>>> have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>>>>> >>>>>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> rob >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>>>>> Hello all! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that >>>>>>>>>>>>>>>> had been going on for sometime, I have all my certs >>>>>>>>>>>>>>>> figured out but the krb5kdc service will not start. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize >>>>>>>>>>>>>>>> realm ITMODEV.GOV - see log file for details [FAILED] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M >>>>>>>>>>>>>>>> for realm ITMODEV.GOV >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos. >>>>>>>>>>>>>>>> sh >>>>>>>>>>>>>>>> t >>>>>>>>>>>>>>>> m >>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create >>>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>>> Tried the command >>>>>>>>>>>>>>>> listed: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No further information found on the proceeding error >>>>>>>>>>>>>>>> above for the kdb5_util command. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>>>> First: don't use instructions which are not related to >>>>>>>>>>>>>>> IPA, please. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions >>>>>>>>>>>>>>> for anything else do not apply here at all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you see 'Server error - while fetching master key ..' >>>>>>>>>>>>>>> it means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>>>>> Does LDAP server work on the replica? What is in its >>>>>>>>>>>>>>> error log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / 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 >>>>> >>>>> >>>> >>> -- >>> 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 > From natxo.asenjo at gmail.com Tue Nov 10 18:02:42 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 10 Nov 2015 19:02:42 +0100 Subject: [Freeipa-users] mastercrl files Message-ID: hi, do we need to keep all the MasterCRL-YYYYMMDD-HHMMSS.der files or can we purge them on a regular basis (say, keep 60 days dump the rest)? $ ls -l | wc -l 3621 this is in a server installed 3 years ago. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From randym at chem.byu.edu Tue Nov 10 18:18:37 2015 From: randym at chem.byu.edu (Randolph Morgan) Date: Tue, 10 Nov 2015 11:18:37 -0700 Subject: [Freeipa-users] FreeIPA and Windows Message-ID: <564234FD.3090707@chem.byu.edu> I am certain that everyone gets tired of answering the same questions over and over, so maybe an update to the documentation would be better. I am trying to get my Windows machines to authenticate against a FreeIPA server running IPA 4.2+ on RHEL 7. I have followed the documentation listed on https://www.freeipa.org/page/Windows_authentication_against_FreeIPA, but there seems to be a few steps missing. In the Configure FreeIPA you are told to create a keytab for the Windows machine in question. After creating the keytab, what do you do with it? It jumps from creating the keytab to configuring Windows but does not say what to do with the keytab and the instructions never reference it again. Would someone please clarify this and is this something we would need to do for each and every Windows machine on our network? Randy -- Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 From rcritten at redhat.com Tue Nov 10 18:25:49 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2015 13:25:49 -0500 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen! .gov> Message-ID: <564236AD.3030502@redhat.com> Gronde, Christopher (Contractor) wrote: > Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? > So what I'd do is this: Do the same cn=mappping ldapsearch on the working master to see what the differences are. Determine if this is an ordering problem or if there is just extra gunk on this non-working master. And compare the versions of 389-ds: rpm -q 389-ds-base. They should be the same. If not then maybe one supports the new ordering and one doesn't. Then: 1. Stop dirsrv 2. cp dse.ldif dse.ldif.mappings 3. edit dse.ldif to match your findings. Either re-order the entries or remove ones you don't need (or both). 4. Start dirsrv 5. Start krb5kdc Step 1 is super important because 389-ds writes dse.ldif on shutdown so all changes made while the service is running will be lost. You can also do this via ldapmodify but it is far easier and less error prone to use your favorite editor in this case. rob From seike at outlook.com Tue Nov 10 18:00:42 2015 From: seike at outlook.com (Seike neg) Date: Tue, 10 Nov 2015 19:00:42 +0100 Subject: [Freeipa-users] Sync with SUN DS 5.2 In-Reply-To: <56420F9E.1030903@redhat.com> References: , <56420F9E.1030903@redhat.com> Message-ID: I want a periodic sync, the ldap is the center of our user management, all credentials are stored there and updated by the HR dept. But I need a kerberos server to deal with the windows clients to provide a kind of SSO. > Date: Tue, 10 Nov 2015 10:39:10 -0500 > From: rcritten at redhat.com > To: seike at outlook.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sync with SUN DS 5.2 > > Seike neg wrote: > > Hello, > > Is there a way to import users and password from SUN DS automatically (script, sync, etc...). > > I have a SUN DS LDAP in the office and I want to do a read only sync from him to a brand new freeipa server. > > The freeipa server is suppose to act as a kerberos, ldap slave and ntp server. > > > > > > It's a little unclear what you want to do. Do you want a periodic sync > or a one-time migration? > > You can use ipa migrate-ds to migrate over LDAP. See > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html > > rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Tue Nov 10 18:32:56 2015 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 10 Nov 2015 14:02:56 -0430 Subject: [Freeipa-users] FreeIPA and Windows In-Reply-To: <564234FD.3090707@chem.byu.edu> References: <564234FD.3090707@chem.byu.edu> Message-ID: <1447180376.3952.57.camel@lgs.com.ve> El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribi?: > I am certain that everyone gets tired of answering the same questions > over and over, so maybe an update to the documentation would be > better.?? > I am trying to get my Windows machines to authenticate against a > FreeIPA > server running IPA 4.2+ on RHEL 7.??I have followed the documentation > listed on > https://www.freeipa.org/page/Windows_authentication_against_FreeIPA, > but > there seems to be a few steps missing. > > In the Configure FreeIPA you are told to create a keytab for the > Windows > machine in question.??After creating the keytab, what do you do with > it???It jumps from creating the keytab to configuring Windows but > does > not say what to do with the keytab and the instructions never > reference > it again.??Would someone please clarify this and is this something we > would need to do for each and every Windows machine on our network? Note that the ipa-getkeytab command is called with the -P option, so it asks for a password: that password is used as a password for the machine principal and is stored in the directory. So no, the keytab is not really used anywhere else and can be deleted. It is the act of generating (with a known password) it that needs to be done for every windows machine in the network. Please use strong, random and different passwords for each windows machine in the network. -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From Christopher.Gronde at fincen.gov Tue Nov 10 18:42:56 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 18:42:56 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <564236AD.3030502@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen! .gov> <564236AD.3030502@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828C142@hqexdb01.hqfincen.gov> This is the mappings from the Master...it looks very different from the replica # ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # mapping, sasl, config dn: cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: mapping # Full Principal, mapping, sasl, config dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: \(.*\)@\(.*\) cn: Full Principal nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) # Name Only, mapping, sasl, config dn: cn=Name Only,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: ^[^:@]+$ cn: Name Only nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 10, 2015 1:26 PM To: Gronde, Christopher (Contractor) ; Rich Megginson ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? > So what I'd do is this: Do the same cn=mappping ldapsearch on the working master to see what the differences are. Determine if this is an ordering problem or if there is just extra gunk on this non-working master. And compare the versions of 389-ds: rpm -q 389-ds-base. They should be the same. If not then maybe one supports the new ordering and one doesn't. Then: 1. Stop dirsrv 2. cp dse.ldif dse.ldif.mappings 3. edit dse.ldif to match your findings. Either re-order the entries or remove ones you don't need (or both). 4. Start dirsrv 5. Start krb5kdc Step 1 is super important because 389-ds writes dse.ldif on shutdown so all changes made while the service is running will be lost. You can also do this via ldapmodify but it is far easier and less error prone to use your favorite editor in this case. rob From orion at cora.nwra.com Tue Nov 10 18:44:12 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 10 Nov 2015 11:44:12 -0700 Subject: [Freeipa-users] Default shell for AD trust users Message-ID: <56423AFC.9040803@cora.nwra.com> I see that AD trust users don't get their posix shell set: # getent passwd user user at ad.nwra.com:*:2260345:2260345:A User:/export/home/user: I can fix this on the clients with override_shell, but that would apply to the IPA domain users as well. Is there some way to configure this in the trust/server? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From Christopher.Gronde at fincen.gov Tue Nov 10 19:14:51 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 10 Nov 2015 19:14:51 +0000 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <564236AD.3030502@redhat.com> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen! .gov> <564236AD.3030502@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828C1BF@hqexdb01.hqfincen.gov> Removed the bad mapping. Krb5kdc service still will not start. Here is the access log. [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory Team,cn=monitor" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid generator,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" scope=2 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=15 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=upgradedb,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=syntax validate,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=schema reload task,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=restore,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=index,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=import,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked attributes,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=export,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=cleanallruv,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=backup,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember rebuild membership,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember map updates,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember export updates,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=abort cleanallruv,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Binary Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bit String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bitwise Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Boolean Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Exact String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Ignore String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Country String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Delivery Method Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Distinguished Name Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Enhanced Guide Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Facsimile Telephone Number Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Fax Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Generalized Time Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Guide Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Integer Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Internationalization Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=JPEG Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Name And Optional UID Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Numeric String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Octet String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=OID Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Postal Address Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Printable String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Space Insensitive String Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Telephone Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Teletex Terminal Identifier Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Telex Number Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=URI Syntax,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=CLEAR,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=CRYPT,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=MD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=NS-MTA-MD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SMD5,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Account Policy Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=attribute uniqueness,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=chaining database,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ldbm database,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvsearch)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvindex)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Linked Attributes,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=fixup linked attributes,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Managed Entries,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=MemberOf Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=PAM Pass Through Auth,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Pass Through Authentication,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=referential integrity postoperation,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Retro Changelog Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Schema Reload,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=schema reload task,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=State Change Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Syntax Validation Task,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=syntax validate,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=USN,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Views,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="objectclass=*" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=7-bit check,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ACL Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config" scope=0 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=ACL Plugin,cn=plugins,cn=config" scope=0 filter="(objectclass=*)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ACL preoperation,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Auto Membership Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember rebuild membership,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember export updates,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember map updates,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Class of Service,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=deref,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=HTTP Client,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Multimaster Replication Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=cleanallruv,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=abort cleanallruv,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Roles Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Legacy Replication Plugin,cn=plugins,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=import,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=export,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=backup,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=restore,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=index,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=upgradedb,cn=tasks,cn=config" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="dc=itmodev,dc=gov" [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=16 tag=48 nentries=0 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=1 filter="(objectclass=nsSaslMapping)" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=5 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=Name Only,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=Full Principal,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 [10/Nov/2015:14:13:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [10/Nov/2015:14:13:04 -0500] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [10/Nov/2015:14:13:04 -0500] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [10/Nov/2015:14:13:04 -0500] conn=1 op=1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=2 filter="(objectClass=*)" attrs=ALL [10/Nov/2015:14:13:04 -0500] conn=1 op=1 RESULT err=0 tag=101 nentries=6 etime=0 [10/Nov/2015:14:13:04 -0500] conn=1 op=2 UNBIND [10/Nov/2015:14:13:04 -0500] conn=1 op=2 fd=64 closed - U1 -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 10, 2015 1:26 PM To: Gronde, Christopher (Contractor) ; Rich Megginson ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) Gronde, Christopher (Contractor) wrote: > Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? > So what I'd do is this: Do the same cn=mappping ldapsearch on the working master to see what the differences are. Determine if this is an ordering problem or if there is just extra gunk on this non-working master. And compare the versions of 389-ds: rpm -q 389-ds-base. They should be the same. If not then maybe one supports the new ordering and one doesn't. Then: 1. Stop dirsrv 2. cp dse.ldif dse.ldif.mappings 3. edit dse.ldif to match your findings. Either re-order the entries or remove ones you don't need (or both). 4. Start dirsrv 5. Start krb5kdc Step 1 is super important because 389-ds writes dse.ldif on shutdown so all changes made while the service is running will be lost. You can also do this via ldapmodify but it is far easier and less error prone to use your favorite editor in this case. rob From ftweedal at redhat.com Tue Nov 10 21:59:20 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Nov 2015 07:59:20 +1000 Subject: [Freeipa-users] mastercrl files In-Reply-To: References: Message-ID: <20151110215920.GE5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote: > hi, > > do we need to keep all the MasterCRL-YYYYMMDD-HHMMSS.der files or can we > purge them on a regular basis (say, keep 60 days dump the rest)? > > $ ls -l | wc -l > 3621 > > this is in a server installed 3 years ago. > > -- > Groeten, > natxo > Hi Natxo, You can purge them. I am not sure why we keep the old ones around; can someone fill me in? Cheers, Fraser > -- > 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 From prasun.gera at gmail.com Tue Nov 10 23:12:04 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 10 Nov 2015 15:12:04 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> Message-ID: I tried using let's encrypt's certs manually, but I think I'm missing something. Let's encrypt creates the following files : cert.pem chain.pem fullchain.pem privkey.pem. I was trying to follow http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i wasn't able to get it to work. That page says, "The certificate in mysite.crt must be signed by the CA used when installing FreeIPA." Since my ipa installation uses the default internal CA, how do I get lets encrypt's certs signed by the ipa CA ? Is that the missing step ? On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera wrote: > Thanks for the discussion. If someone can update the documentation with > mozilla style old, intermediate and modern cipher lists for mod_nss, that > would be great. Better still would be to add that option to the installer > scripts so that you can choose it during installation. Integrating that in > the package would also have the added benefit of settings remaining up to > date without manual intervention as standards evolve. > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale > wrote: > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: >> > Prasun Gera wrote: >> > > Thanks. After the changes, most things seem to be in order. I see two >> > > orange flags though: >> > > >> > > Secure Client-Initiated Renegotiation *Supported* *DoS >> DANGER* (more >> > > info >> > > < >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks >> >) >> > >> > Renegotiation is required for the CA so you need to leave this enabled. >> > >> > > Session resumption (caching) *No (IDs assigned but not >> accepted)* >> > >> > I'll need to look at this in more detail. At worst it would slow new >> > connection performance slightly as it means every connection requires a >> > full SSL/TLS handshake. I don't think it's a show-stopper. >> > >> Definitely not a show-stopper. The main reason this is an "orange" >> alert in SSLLabs is because the server is assigning Session IDs but >> then ignoring them; although confusing it is a fairly common default >> behaviour and doesn't cause any issues with compliant client >> implementation >> >> > rob >> > >> > > >> > > Are these relevant/serious ? Can they be mitigated ? >> > > >> > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden > > > > wrote: >> > > >> > > Prasun Gera wrote: >> > > > Yes, that's what I was planning to do. i.e. Convert cipher >> names from >> > > > SSL to NSS. I wasn't sure about the other settings though. Is >> there an >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, >> are there >> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow >> using >> > > > generated DH parameters instead of standard ones ? For SSL, the >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd >> DHParameters >> > > > "{path to dhparams.pem}"' after generating the params. >> > > >> > > NSS does not let the user specify cipher order. It uses its own >> internal >> > > sorting from strongest to weakest. >> > > >> > > HSTS is a header and not dependent upon SSL provider. >> > > >> > > mod_nss doesn't support DH ciphers. >> > > >> > > rob >> > > >> > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < >> ftweedal at redhat.com >> > > > >> >> wrote: >> > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: >> > > > > Thanks for the ticket information. I would still be >> interested in >> > > > > configuring mod_nss properly (irrespective of whether the >> certs are ipa >> > > > > generated or 3rd party). These are the worrying notes >> from ssllabs test: >> > > > > >> > > > > The server supports only older protocols, but not the >> current best TLS 1.2. >> > > > > Grade capped to C. >> > > > > This server accepts the RC4 cipher, which is weak. Grade >> capped to B. >> > > > > The server does not support Forward Secrecy with the >> reference browsers. >> > > > > >> > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a >> > > > starting point. See also the "Cipher names correspondence >> table" on >> > > > the same page for translating it to cipher names understood >> by NSS >> > > > to construct a valid setting for the `NSSCipherSuite' >> directive. >> > > > >> > > > [1] >> > > > >> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility >> > > > >> > > > Cheers, >> > > > Fraser >> > > > >> > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale >> > > > >> > > >> wrote: >> > > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera >> wrote: >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui >> > > accessible >> > > > publicly. >> > > > > > I'm >> > > > > > > using a stock configuration which uses the certs >> signed by >> > > > ipa's CA for >> > > > > > the >> > > > > > > webui. This is mostly for convenience since it manages >> > > renewals >> > > > > > seamlessly. >> > > > > > > This, however, requires users to add the CA as trusted >> > > to their >> > > > > > browsers. A >> > > > > > > promising alternative to this is >> https://letsencrypt.org/, >> > > > which issues >> > > > > > > browser trusted certs, and will manage auto renewals >> too (in >> > > > the future). >> > > > > > > As a feature request, it would be nice to have closer >> > > > integration between >> > > > > > > ipa and the letsencrypt client which would make >> managing >> > > certs >> > > > simple. >> > > > > > I'm >> > > > > > > about to set this up manually right now using the >> > > external ssl >> > > > certs >> > > > > > guide. >> > > > > > > >> > > > > > Let's Encrypt is on our radar. I like the idea of being >> > > able to >> > > > > > install FreeIPA with publicly-trusted certs for HTTP and >> > > LDAP from >> > > > > > the beginning. This would require some work in >> > > ipa-server-install >> > > > > > in addition to certmonger support and a good, stable >> Let's >> > > Encrypt / >> > > > > > ACME client implementation for Apache on Fedora. >> > > > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs is a >> common >> > > activity >> > > > > > so I filed a ticket: >> > > https://fedorahosted.org/freeipa/ticket/5431 >> > > > > > >> > > > > > Cheers, >> > > > > > Fraser >> > > > > > >> > > > > > > Secondly, since the webui uses mod_nss, how would one >> set it >> > > > up to prefer >> > > > > > > security over compatibility with older clients ? The >> vast >> > > > majority of >> > > > > > > documentation online (for eg. >> > > > > > > >> > > > >> > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) >> is >> > > > > > about >> > > > > > > mod_ssl and I think the configuration doesn't transfer >> > > directly to >> > > > > > mod_nss. >> > > > > > > Since this is the only web facing component, I would >> like to >> > > > set it up to >> > > > > > > use stringent requirements. Right now, a test on >> > > > > > > https://www.ssllabs.com/ssltest/ and >> > > > https://weakdh.org/sysadmin.html >> > > > > > > identifies >> > > > > > > several issues. Since these things are not really my >> area of >> > > > expertise, I >> > > > > > > would like some documentation regarding this. Also, >> > > would manually >> > > > > > > modifying any of the config files be overwritten by a >> > > yum update ? >> > > > > > >> > > > > > > -- >> > > > > > > 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 >> > > > > > >> > > > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Nov 10 23:31:58 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Nov 2015 09:31:58 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> Message-ID: <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: > I tried using let's encrypt's certs manually, but I think I'm missing > something. Let's encrypt creates the following files : cert.pem chain.pem > fullchain.pem privkey.pem. I was trying to follow > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i > wasn't able to get it to work. That page says, "The certificate in > mysite.crt must be signed by the CA used when installing FreeIPA." Since my > ipa installation uses the default internal CA, how do I get lets encrypt's > certs signed by the ipa CA ? Is that the missing step ? > I do not think that text is correct, in the case of a publicy-trusted certificate (i.e. the server cert is chained to a trusted issuer). Just ignore that text and follow the steps. Does it work? Cheers, Fraser > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera wrote: > > > Thanks for the discussion. If someone can update the documentation with > > mozilla style old, intermediate and modern cipher lists for mod_nss, that > > would be great. Better still would be to add that option to the installer > > scripts so that you can choose it during installation. Integrating that in > > the package would also have the added benefit of settings remaining up to > > date without manual intervention as standards evolve. > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale > > wrote: > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > >> > Prasun Gera wrote: > >> > > Thanks. After the changes, most things seem to be in order. I see two > >> > > orange flags though: > >> > > > >> > > Secure Client-Initiated Renegotiation *Supported* *DoS > >> DANGER* (more > >> > > info > >> > > < > >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > >> >) > >> > > >> > Renegotiation is required for the CA so you need to leave this enabled. > >> > > >> > > Session resumption (caching) *No (IDs assigned but not > >> accepted)* > >> > > >> > I'll need to look at this in more detail. At worst it would slow new > >> > connection performance slightly as it means every connection requires a > >> > full SSL/TLS handshake. I don't think it's a show-stopper. > >> > > >> Definitely not a show-stopper. The main reason this is an "orange" > >> alert in SSLLabs is because the server is assigning Session IDs but > >> then ignoring them; although confusing it is a fairly common default > >> behaviour and doesn't cause any issues with compliant client > >> implementation > >> > >> > rob > >> > > >> > > > >> > > Are these relevant/serious ? Can they be mitigated ? > >> > > > >> > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden >> > > > wrote: > >> > > > >> > > Prasun Gera wrote: > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher > >> names from > >> > > > SSL to NSS. I wasn't sure about the other settings though. Is > >> there an > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, > >> are there > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow > >> using > >> > > > generated DH parameters instead of standard ones ? For SSL, the > >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd > >> DHParameters > >> > > > "{path to dhparams.pem}"' after generating the params. > >> > > > >> > > NSS does not let the user specify cipher order. It uses its own > >> internal > >> > > sorting from strongest to weakest. > >> > > > >> > > HSTS is a header and not dependent upon SSL provider. > >> > > > >> > > mod_nss doesn't support DH ciphers. > >> > > > >> > > rob > >> > > > >> > > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > >> ftweedal at redhat.com > >> > > > >> > >> wrote: > >> > > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote: > >> > > > > Thanks for the ticket information. I would still be > >> interested in > >> > > > > configuring mod_nss properly (irrespective of whether the > >> certs are ipa > >> > > > > generated or 3rd party). These are the worrying notes > >> from ssllabs test: > >> > > > > > >> > > > > The server supports only older protocols, but not the > >> current best TLS 1.2. > >> > > > > Grade capped to C. > >> > > > > This server accepts the RC4 cipher, which is weak. Grade > >> capped to B. > >> > > > > The server does not support Forward Secrecy with the > >> reference browsers. > >> > > > > > >> > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a > >> > > > starting point. See also the "Cipher names correspondence > >> table" on > >> > > > the same page for translating it to cipher names understood > >> by NSS > >> > > > to construct a valid setting for the `NSSCipherSuite' > >> directive. > >> > > > > >> > > > [1] > >> > > > > >> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > >> > > > > >> > > > Cheers, > >> > > > Fraser > >> > > > > >> > > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > >> > > > > >> > > >> wrote: > >> > > > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera > >> wrote: > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > >> > > accessible > >> > > > publicly. > >> > > > > > I'm > >> > > > > > > using a stock configuration which uses the certs > >> signed by > >> > > > ipa's CA for > >> > > > > > the > >> > > > > > > webui. This is mostly for convenience since it manages > >> > > renewals > >> > > > > > seamlessly. > >> > > > > > > This, however, requires users to add the CA as trusted > >> > > to their > >> > > > > > browsers. A > >> > > > > > > promising alternative to this is > >> https://letsencrypt.org/, > >> > > > which issues > >> > > > > > > browser trusted certs, and will manage auto renewals > >> too (in > >> > > > the future). > >> > > > > > > As a feature request, it would be nice to have closer > >> > > > integration between > >> > > > > > > ipa and the letsencrypt client which would make > >> managing > >> > > certs > >> > > > simple. > >> > > > > > I'm > >> > > > > > > about to set this up manually right now using the > >> > > external ssl > >> > > > certs > >> > > > > > guide. > >> > > > > > > > >> > > > > > Let's Encrypt is on our radar. I like the idea of being > >> > > able to > >> > > > > > install FreeIPA with publicly-trusted certs for HTTP and > >> > > LDAP from > >> > > > > > the beginning. This would require some work in > >> > > ipa-server-install > >> > > > > > in addition to certmonger support and a good, stable > >> Let's > >> > > Encrypt / > >> > > > > > ACME client implementation for Apache on Fedora. > >> > > > > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs is a > >> common > >> > > activity > >> > > > > > so I filed a ticket: > >> > > https://fedorahosted.org/freeipa/ticket/5431 > >> > > > > > > >> > > > > > Cheers, > >> > > > > > Fraser > >> > > > > > > >> > > > > > > Secondly, since the webui uses mod_nss, how would one > >> set it > >> > > > up to prefer > >> > > > > > > security over compatibility with older clients ? The > >> vast > >> > > > majority of > >> > > > > > > documentation online (for eg. > >> > > > > > > > >> > > > > >> > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > >> is > >> > > > > > about > >> > > > > > > mod_ssl and I think the configuration doesn't transfer > >> > > directly to > >> > > > > > mod_nss. > >> > > > > > > Since this is the only web facing component, I would > >> like to > >> > > > set it up to > >> > > > > > > use stringent requirements. Right now, a test on > >> > > > > > > https://www.ssllabs.com/ssltest/ and > >> > > > https://weakdh.org/sysadmin.html > >> > > > > > > identifies > >> > > > > > > several issues. Since these things are not really my > >> area of > >> > > > expertise, I > >> > > > > > > would like some documentation regarding this. Also, > >> > > would manually > >> > > > > > > modifying any of the config files be overwritten by a > >> > > yum update ? > >> > > > > > > >> > > > > > > -- > >> > > > > > > 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 > >> > > > > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > > > From prasun.gera at gmail.com Tue Nov 10 23:44:19 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 10 Nov 2015 15:44:19 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> References: <20151105004459.GA20018@dhcp-40-8.bne.redhat.com> <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> Message-ID: No it didn't quite work. I ran ipa-server-certinstall -w /etc/letsencrypt/live/ example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem which gives The full certificate chain is not present in /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ example.com/fullchain.pem On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale wrote: > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: > > I tried using let's encrypt's certs manually, but I think I'm missing > > something. Let's encrypt creates the following files : cert.pem > chain.pem > > fullchain.pem privkey.pem. I was trying to follow > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > but i > > wasn't able to get it to work. That page says, "The certificate in > > mysite.crt must be signed by the CA used when installing FreeIPA." Since > my > > ipa installation uses the default internal CA, how do I get lets > encrypt's > > certs signed by the ipa CA ? Is that the missing step ? > > > I do not think that text is correct, in the case of a > publicy-trusted certificate (i.e. the server cert is chained to a > trusted issuer). > > Just ignore that text and follow the steps. Does it work? > > Cheers, > Fraser > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera > wrote: > > > > > Thanks for the discussion. If someone can update the documentation with > > > mozilla style old, intermediate and modern cipher lists for mod_nss, > that > > > would be great. Better still would be to add that option to the > installer > > > scripts so that you can choose it during installation. Integrating > that in > > > the package would also have the added benefit of settings remaining up > to > > > date without manual intervention as standards evolve. > > > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale > > > wrote: > > > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > > >> > Prasun Gera wrote: > > >> > > Thanks. After the changes, most things seem to be in order. I see > two > > >> > > orange flags though: > > >> > > > > >> > > Secure Client-Initiated Renegotiation *Supported* *DoS > > >> DANGER* (more > > >> > > info > > >> > > < > > >> > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > > >> >) > > >> > > > >> > Renegotiation is required for the CA so you need to leave this > enabled. > > >> > > > >> > > Session resumption (caching) *No (IDs assigned but not > > >> accepted)* > > >> > > > >> > I'll need to look at this in more detail. At worst it would slow new > > >> > connection performance slightly as it means every connection > requires a > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. > > >> > > > >> Definitely not a show-stopper. The main reason this is an "orange" > > >> alert in SSLLabs is because the server is assigning Session IDs but > > >> then ignoring them; although confusing it is a fairly common default > > >> behaviour and doesn't cause any issues with compliant client > > >> implementation > > >> > > >> > rob > > >> > > > >> > > > > >> > > Are these relevant/serious ? Can they be mitigated ? > > >> > > > > >> > > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < > rcritten at redhat.com > > >> > > > wrote: > > >> > > > > >> > > Prasun Gera wrote: > > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher > > >> names from > > >> > > > SSL to NSS. I wasn't sure about the other settings though. > Is > > >> there an > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? > Similarly, > > >> are there > > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS > allow > > >> using > > >> > > > generated DH parameters instead of standard ones ? For SSL, > the > > >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd > > >> DHParameters > > >> > > > "{path to dhparams.pem}"' after generating the params. > > >> > > > > >> > > NSS does not let the user specify cipher order. It uses its > own > > >> internal > > >> > > sorting from strongest to weakest. > > >> > > > > >> > > HSTS is a header and not dependent upon SSL provider. > > >> > > > > >> > > mod_nss doesn't support DH ciphers. > > >> > > > > >> > > rob > > >> > > > > >> > > > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > > >> ftweedal at redhat.com > > >> > > > >> > > >> wrote: > > >> > > > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera > wrote: > > >> > > > > Thanks for the ticket information. I would still be > > >> interested in > > >> > > > > configuring mod_nss properly (irrespective of whether > the > > >> certs are ipa > > >> > > > > generated or 3rd party). These are the worrying notes > > >> from ssllabs test: > > >> > > > > > > >> > > > > The server supports only older protocols, but not the > > >> current best TLS 1.2. > > >> > > > > Grade capped to C. > > >> > > > > This server accepts the RC4 cipher, which is weak. > Grade > > >> capped to B. > > >> > > > > The server does not support Forward Secrecy with the > > >> reference browsers. > > >> > > > > > > >> > > > Use the "Modern" cipher suite[1] recommended by Mozilla > as a > > >> > > > starting point. See also the "Cipher names > correspondence > > >> table" on > > >> > > > the same page for translating it to cipher names > understood > > >> by NSS > > >> > > > to construct a valid setting for the `NSSCipherSuite' > > >> directive. > > >> > > > > > >> > > > [1] > > >> > > > > > >> > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > >> > > > > > >> > > > Cheers, > > >> > > > Fraser > > >> > > > > > >> > > > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > >> > > > > > >> > > >> > wrote: > > >> > > > > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun > Gera > > >> wrote: > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > > >> > > accessible > > >> > > > publicly. > > >> > > > > > I'm > > >> > > > > > > using a stock configuration which uses the certs > > >> signed by > > >> > > > ipa's CA for > > >> > > > > > the > > >> > > > > > > webui. This is mostly for convenience since it > manages > > >> > > renewals > > >> > > > > > seamlessly. > > >> > > > > > > This, however, requires users to add the CA as > trusted > > >> > > to their > > >> > > > > > browsers. A > > >> > > > > > > promising alternative to this is > > >> https://letsencrypt.org/, > > >> > > > which issues > > >> > > > > > > browser trusted certs, and will manage auto > renewals > > >> too (in > > >> > > > the future). > > >> > > > > > > As a feature request, it would be nice to have > closer > > >> > > > integration between > > >> > > > > > > ipa and the letsencrypt client which would make > > >> managing > > >> > > certs > > >> > > > simple. > > >> > > > > > I'm > > >> > > > > > > about to set this up manually right now using the > > >> > > external ssl > > >> > > > certs > > >> > > > > > guide. > > >> > > > > > > > > >> > > > > > Let's Encrypt is on our radar. I like the idea of > being > > >> > > able to > > >> > > > > > install FreeIPA with publicly-trusted certs for > HTTP and > > >> > > LDAP from > > >> > > > > > the beginning. This would require some work in > > >> > > ipa-server-install > > >> > > > > > in addition to certmonger support and a good, stable > > >> Let's > > >> > > Encrypt / > > >> > > > > > ACME client implementation for Apache on Fedora. > > >> > > > > > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs is a > > >> common > > >> > > activity > > >> > > > > > so I filed a ticket: > > >> > > https://fedorahosted.org/freeipa/ticket/5431 > > >> > > > > > > > >> > > > > > Cheers, > > >> > > > > > Fraser > > >> > > > > > > > >> > > > > > > Secondly, since the webui uses mod_nss, how would > one > > >> set it > > >> > > > up to prefer > > >> > > > > > > security over compatibility with older clients ? > The > > >> vast > > >> > > > majority of > > >> > > > > > > documentation online (for eg. > > >> > > > > > > > > >> > > > > > >> > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > > >> is > > >> > > > > > about > > >> > > > > > > mod_ssl and I think the configuration doesn't > transfer > > >> > > directly to > > >> > > > > > mod_nss. > > >> > > > > > > Since this is the only web facing component, I > would > > >> like to > > >> > > > set it up to > > >> > > > > > > use stringent requirements. Right now, a test on > > >> > > > > > > https://www.ssllabs.com/ssltest/ and > > >> > > > https://weakdh.org/sysadmin.html > > >> > > > > > > identifies > > >> > > > > > > several issues. Since these things are not really > my > > >> area of > > >> > > > expertise, I > > >> > > > > > > would like some documentation regarding this. > Also, > > >> > > would manually > > >> > > > > > > modifying any of the config files be overwritten > by a > > >> > > yum update ? > > >> > > > > > > > >> > > > > > > -- > > >> > > > > > > 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 > > >> > > > > > > > >> > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Wed Nov 11 00:54:02 2015 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 10 Nov 2015 20:24:02 -0430 Subject: [Freeipa-users] FreeIPA and Windows In-Reply-To: <56427A85.7090809@chem.byu.edu> References: <564234FD.3090707@chem.byu.edu> <1447180376.3952.57.camel@lgs.com.ve> <56423CCB.6060504@chem.byu.edu> <1447195806.3952.67.camel@lgs.com.ve> <56427A85.7090809@chem.byu.edu> Message-ID: <1447203242.3952.76.camel@lgs.com.ve> El mar, 10-11-2015 a las 16:15 -0700, Randolph Morgan escribi?: > Yes they are in the same DNS domain as the IPAserver.??I am able to > resolve the server address.??Which side would you like more > information > on the server side or the client side.??We are not running any AD > domains, so this is not a Windows based system.??We are running > FreeIPA > 4.2+ on RHEL 7.1 using the stock Samba from RHEL.??On the client side > I > am running Windows 10 and I have installed MIT Kerberos version > 4.01.?? > In the MIT ticket manager I show a tgt and it works as it > should.??But > from the command prompt in windows if I do a klist it reports: > ?????????????????????????????????????????????????????????????Current > LogonId is 0:0x6320a > > ?????????????????????????????????????????????????????????????Cached > Tickets: (0) > > So even though MIT Kerberos shows a successful negotiation with IPA > and > a ticket is received, windows reports back the above when a klist is > run.? I think that is the problem, you shouldn't use MIT kerberos. The commands listed on the howto: 1. ksetup /setdomain [REALM NAME] 2. ksetup /addkdc [REALM NAME] [kdc DNS name] 3. ksetup /addkpasswd [REALM NAME] [kdc DNS name] 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) 5. ksetup /mapuser * * are meant to be run with windows native ksetup command. The native windows kerberos libraries cannot see tickets obtained with MT kerberos. Best regards > ?What I am trying to do is get the two to talk to each other, but I > have not had any success as of yet.??I have edited the krb5.ini with > the > correct information, and rebooted the machine multiple times with no > change.??Any help here would be really appreciated, we are taking > this > system live over the weekend and would really love to have this part > fixed. > > Randy > > Randy Morgan > CSR > Department of Chemistry and Biochemistry > Brigham Young University > 801-422-4100 > > On 11/10/2015 3:50 PM, Loris Santamaria wrote: > > El mar, 10-11-2015 a las 11:51 -0700, Randolph Morgan escribi?: > > > Ok, that makes sense, but could we not just create the host in > > > the > > > IPA > > > UI as part of the DNS? > > That isn't enough, the dns object just maps to an ip address, you > > have > > to create a "host" object with ipa host-add, that object is needed > > to > > store kerberos principal and password for the host. > > > > > Also we seem to be having some difficulty with > > > another part of the process, that is getting the Windows machines > > > to > > > even acknowledge that they have the ability to talk with the kdc. > > > Following the commands yields only that the windows machine is > > > unable > > > to > > > locate the kdc, are we missing something???Is this one of the > > > issues > > > related to different versions of Kerberos, e.g. MIT vs Heimdal. > > You should check for dns inconsistencies first, are the windows > > machines in the same dns domain as windows? Can they solve the > > addresses of the ipa servers? If that doesn't help you should post > > more > > details of your setup... > > > > Best regards > > > > > > > On 11/10/2015 11:32 AM, Loris Santamaria wrote: > > > > El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribi?: > > > > > I am certain that everyone gets tired of answering the same > > > > > questions > > > > > over and over, so maybe an update to the documentation would > > > > > be > > > > > better. > > > > > I am trying to get my Windows machines to authenticate > > > > > against a > > > > > FreeIPA > > > > > server running IPA 4.2+ on RHEL 7.??I have followed the > > > > > documentation > > > > > listed on > > > > > https://www.freeipa.org/page/Windows_authentication_against_F > > > > > reeI > > > > > PA, > > > > > but > > > > > there seems to be a few steps missing. > > > > > > > > > > In the Configure FreeIPA you are told to create a keytab for > > > > > the > > > > > Windows > > > > > machine in question.??After creating the keytab, what do you > > > > > do > > > > > with > > > > > it???It jumps from creating the keytab to configuring Windows > > > > > but > > > > > does > > > > > not say what to do with the keytab and the instructions never > > > > > reference > > > > > it again.??Would someone please clarify this and is this > > > > > something we > > > > > would need to do for each and every Windows machine on our > > > > > network? > > > > Note that the ipa-getkeytab command is called with the -P > > > > option, > > > > so it > > > > asks for a password: that password is used as a password for > > > > the > > > > machine principal and is stored in the directory. > > > > > > > > So no, the keytab is not really used anywhere else and can be > > > > deleted. > > > > It is the act of generating (with a known password) it that > > > > needs > > > > to be > > > > done for every windows machine in the network. Please use > > > > strong, > > > > random and different passwords for each windows machine in the > > > > network. > > > > > > > > > -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From ftweedal at redhat.com Wed Nov 11 01:04:34 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Nov 2015 11:04:34 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> Message-ID: <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote: > No it didn't quite work. > > I ran ipa-server-certinstall -w /etc/letsencrypt/live/ > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem > > which gives The full certificate chain is not present in > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ > example.com/fullchain.pem > It looks like this error is triggered when there is no self-signed certificate in the trust chain (fullchain.pem). Could you confirm that this is the case, and if so, could you try appending the root certificate to fullchain.pem and trying again? It may be that ipa-server-certinstall assumes that your server certs are signed by the same CA as your IPA CA certificate, which need not be the case. > > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale > wrote: > > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: > > > I tried using let's encrypt's certs manually, but I think I'm missing > > > something. Let's encrypt creates the following files : cert.pem > > chain.pem > > > fullchain.pem privkey.pem. I was trying to follow > > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > but i > > > wasn't able to get it to work. That page says, "The certificate in > > > mysite.crt must be signed by the CA used when installing FreeIPA." Since > > my > > > ipa installation uses the default internal CA, how do I get lets > > encrypt's > > > certs signed by the ipa CA ? Is that the missing step ? > > > > > I do not think that text is correct, in the case of a > > publicy-trusted certificate (i.e. the server cert is chained to a > > trusted issuer). > > > > Just ignore that text and follow the steps. Does it work? > > > > Cheers, > > Fraser > > > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera > > wrote: > > > > > > > Thanks for the discussion. If someone can update the documentation with > > > > mozilla style old, intermediate and modern cipher lists for mod_nss, > > that > > > > would be great. Better still would be to add that option to the > > installer > > > > scripts so that you can choose it during installation. Integrating > > that in > > > > the package would also have the added benefit of settings remaining up > > to > > > > date without manual intervention as standards evolve. > > > > > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale > > > > wrote: > > > > > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > > > >> > Prasun Gera wrote: > > > >> > > Thanks. After the changes, most things seem to be in order. I see > > two > > > >> > > orange flags though: > > > >> > > > > > >> > > Secure Client-Initiated Renegotiation *Supported* *DoS > > > >> DANGER* (more > > > >> > > info > > > >> > > < > > > >> > > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > > > >> >) > > > >> > > > > >> > Renegotiation is required for the CA so you need to leave this > > enabled. > > > >> > > > > >> > > Session resumption (caching) *No (IDs assigned but not > > > >> accepted)* > > > >> > > > > >> > I'll need to look at this in more detail. At worst it would slow new > > > >> > connection performance slightly as it means every connection > > requires a > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. > > > >> > > > > >> Definitely not a show-stopper. The main reason this is an "orange" > > > >> alert in SSLLabs is because the server is assigning Session IDs but > > > >> then ignoring them; although confusing it is a fairly common default > > > >> behaviour and doesn't cause any issues with compliant client > > > >> implementation > > > >> > > > >> > rob > > > >> > > > > >> > > > > > >> > > Are these relevant/serious ? Can they be mitigated ? > > > >> > > > > > >> > > > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < > > rcritten at redhat.com > > > >> > > > wrote: > > > >> > > > > > >> > > Prasun Gera wrote: > > > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher > > > >> names from > > > >> > > > SSL to NSS. I wasn't sure about the other settings though. > > Is > > > >> there an > > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? > > Similarly, > > > >> are there > > > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS > > allow > > > >> using > > > >> > > > generated DH parameters instead of standard ones ? For SSL, > > the > > > >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd > > > >> DHParameters > > > >> > > > "{path to dhparams.pem}"' after generating the params. > > > >> > > > > > >> > > NSS does not let the user specify cipher order. It uses its > > own > > > >> internal > > > >> > > sorting from strongest to weakest. > > > >> > > > > > >> > > HSTS is a header and not dependent upon SSL provider. > > > >> > > > > > >> > > mod_nss doesn't support DH ciphers. > > > >> > > > > > >> > > rob > > > >> > > > > > >> > > > > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > > > >> ftweedal at redhat.com > > > >> > > > >> > > > >> wrote: > > > >> > > > > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera > > wrote: > > > >> > > > > Thanks for the ticket information. I would still be > > > >> interested in > > > >> > > > > configuring mod_nss properly (irrespective of whether > > the > > > >> certs are ipa > > > >> > > > > generated or 3rd party). These are the worrying notes > > > >> from ssllabs test: > > > >> > > > > > > > >> > > > > The server supports only older protocols, but not the > > > >> current best TLS 1.2. > > > >> > > > > Grade capped to C. > > > >> > > > > This server accepts the RC4 cipher, which is weak. > > Grade > > > >> capped to B. > > > >> > > > > The server does not support Forward Secrecy with the > > > >> reference browsers. > > > >> > > > > > > > >> > > > Use the "Modern" cipher suite[1] recommended by Mozilla > > as a > > > >> > > > starting point. See also the "Cipher names > > correspondence > > > >> table" on > > > >> > > > the same page for translating it to cipher names > > understood > > > >> by NSS > > > >> > > > to construct a valid setting for the `NSSCipherSuite' > > > >> directive. > > > >> > > > > > > >> > > > [1] > > > >> > > > > > > >> > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > >> > > > > > > >> > > > Cheers, > > > >> > > > Fraser > > > >> > > > > > > >> > > > > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > >> > > > > > > >> > > >> > > wrote: > > > >> > > > > > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun > > Gera > > > >> wrote: > > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui > > > >> > > accessible > > > >> > > > publicly. > > > >> > > > > > I'm > > > >> > > > > > > using a stock configuration which uses the certs > > > >> signed by > > > >> > > > ipa's CA for > > > >> > > > > > the > > > >> > > > > > > webui. This is mostly for convenience since it > > manages > > > >> > > renewals > > > >> > > > > > seamlessly. > > > >> > > > > > > This, however, requires users to add the CA as > > trusted > > > >> > > to their > > > >> > > > > > browsers. A > > > >> > > > > > > promising alternative to this is > > > >> https://letsencrypt.org/, > > > >> > > > which issues > > > >> > > > > > > browser trusted certs, and will manage auto > > renewals > > > >> too (in > > > >> > > > the future). > > > >> > > > > > > As a feature request, it would be nice to have > > closer > > > >> > > > integration between > > > >> > > > > > > ipa and the letsencrypt client which would make > > > >> managing > > > >> > > certs > > > >> > > > simple. > > > >> > > > > > I'm > > > >> > > > > > > about to set this up manually right now using the > > > >> > > external ssl > > > >> > > > certs > > > >> > > > > > guide. > > > >> > > > > > > > > > >> > > > > > Let's Encrypt is on our radar. I like the idea of > > being > > > >> > > able to > > > >> > > > > > install FreeIPA with publicly-trusted certs for > > HTTP and > > > >> > > LDAP from > > > >> > > > > > the beginning. This would require some work in > > > >> > > ipa-server-install > > > >> > > > > > in addition to certmonger support and a good, stable > > > >> Let's > > > >> > > Encrypt / > > > >> > > > > > ACME client implementation for Apache on Fedora. > > > >> > > > > > > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs is a > > > >> common > > > >> > > activity > > > >> > > > > > so I filed a ticket: > > > >> > > https://fedorahosted.org/freeipa/ticket/5431 > > > >> > > > > > > > > >> > > > > > Cheers, > > > >> > > > > > Fraser > > > >> > > > > > > > > >> > > > > > > Secondly, since the webui uses mod_nss, how would > > one > > > >> set it > > > >> > > > up to prefer > > > >> > > > > > > security over compatibility with older clients ? > > The > > > >> vast > > > >> > > > majority of > > > >> > > > > > > documentation online (for eg. > > > >> > > > > > > > > > >> > > > > > > >> > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > > > >> is > > > >> > > > > > about > > > >> > > > > > > mod_ssl and I think the configuration doesn't > > transfer > > > >> > > directly to > > > >> > > > > > mod_nss. > > > >> > > > > > > Since this is the only web facing component, I > > would > > > >> like to > > > >> > > > set it up to > > > >> > > > > > > use stringent requirements. Right now, a test on > > > >> > > > > > > https://www.ssllabs.com/ssltest/ and > > > >> > > > https://weakdh.org/sysadmin.html > > > >> > > > > > > identifies > > > >> > > > > > > several issues. Since these things are not really > > my > > > >> area of > > > >> > > > expertise, I > > > >> > > > > > > would like some documentation regarding this. > > Also, > > > >> > > would manually > > > >> > > > > > > modifying any of the config files be overwritten > > by a > > > >> > > yum update ? > > > >> > > > > > > > > >> > > > > > > -- > > > >> > > > > > > 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 > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > From david at kreitschmann.de Wed Nov 11 02:28:44 2015 From: david at kreitschmann.de (David Kreitschmann) Date: Wed, 11 Nov 2015 03:28:44 +0100 Subject: [Freeipa-users] FreeIPA and Windows In-Reply-To: <1447203242.3952.76.camel@lgs.com.ve> References: <564234FD.3090707@chem.byu.edu> <1447180376.3952.57.camel@lgs.com.ve> <56423CCB.6060504@chem.byu.edu> <1447195806.3952.67.camel@lgs.com.ve> <56427A85.7090809@chem.byu.edu> <1447203242.3952.76.camel@lgs.com.ve> Message-ID: <6962884D-8DEC-4080-99B3-EB9639B877F3@kreitschmann.de> If you use the MSLSA credential cache MIT kerberos works. kinit -c MSLSA: user at REALM Not sure about the MIT ticket manager. Am 11.11.2015 um 01:54 schrieb Loris Santamaria : > > > El mar, 10-11-2015 a las 16:15 -0700, Randolph Morgan escribi?: >> Yes they are in the same DNS domain as the IPAserver. I am able to >> resolve the server address. Which side would you like more >> information >> on the server side or the client side. We are not running any AD >> domains, so this is not a Windows based system. We are running >> FreeIPA >> 4.2+ on RHEL 7.1 using the stock Samba from RHEL. On the client side >> I >> am running Windows 10 and I have installed MIT Kerberos version >> 4.01. >> In the MIT ticket manager I show a tgt and it works as it >> should. But >> from the command prompt in windows if I do a klist it reports: >> Current >> LogonId is 0:0x6320a >> >> Cached >> Tickets: (0) >> >> So even though MIT Kerberos shows a successful negotiation with IPA >> and >> a ticket is received, windows reports back the above when a klist is >> run. > > I think that is the problem, you shouldn't use MIT kerberos. > > The commands listed on the howto: > > 1. ksetup /setdomain [REALM NAME] > 2. ksetup /addkdc [REALM NAME] [kdc DNS name] > 3. ksetup /addkpasswd [REALM NAME] [kdc DNS name] > 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) > 5. ksetup /mapuser * * > > are meant to be run with windows native ksetup command. The native > windows kerberos libraries cannot see tickets obtained with MT > kerberos. > > Best regards > > >> What I am trying to do is get the two to talk to each other, but I >> have not had any success as of yet. I have edited the krb5.ini with >> the >> correct information, and rebooted the machine multiple times with no >> change. Any help here would be really appreciated, we are taking >> this >> system live over the weekend and would really love to have this part >> fixed. >> >> Randy >> >> Randy Morgan >> CSR >> Department of Chemistry and Biochemistry >> Brigham Young University >> 801-422-4100 >> >> On 11/10/2015 3:50 PM, Loris Santamaria wrote: >>> El mar, 10-11-2015 a las 11:51 -0700, Randolph Morgan escribi?: >>>> Ok, that makes sense, but could we not just create the host in >>>> the >>>> IPA >>>> UI as part of the DNS? >>> That isn't enough, the dns object just maps to an ip address, you >>> have >>> to create a "host" object with ipa host-add, that object is needed >>> to >>> store kerberos principal and password for the host. >>> >>>> Also we seem to be having some difficulty with >>>> another part of the process, that is getting the Windows machines >>>> to >>>> even acknowledge that they have the ability to talk with the kdc. >>>> Following the commands yields only that the windows machine is >>>> unable >>>> to >>>> locate the kdc, are we missing something? Is this one of the >>>> issues >>>> related to different versions of Kerberos, e.g. MIT vs Heimdal. >>> You should check for dns inconsistencies first, are the windows >>> machines in the same dns domain as windows? Can they solve the >>> addresses of the ipa servers? If that doesn't help you should post >>> more >>> details of your setup... >>> >>> Best regards >>> >>> >>>> On 11/10/2015 11:32 AM, Loris Santamaria wrote: >>>>> El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribi?: >>>>>> I am certain that everyone gets tired of answering the same >>>>>> questions >>>>>> over and over, so maybe an update to the documentation would >>>>>> be >>>>>> better. >>>>>> I am trying to get my Windows machines to authenticate >>>>>> against a >>>>>> FreeIPA >>>>>> server running IPA 4.2+ on RHEL 7. I have followed the >>>>>> documentation >>>>>> listed on >>>>>> https://www.freeipa.org/page/Windows_authentication_against_F >>>>>> reeI >>>>>> PA, >>>>>> but >>>>>> there seems to be a few steps missing. >>>>>> >>>>>> In the Configure FreeIPA you are told to create a keytab for >>>>>> the >>>>>> Windows >>>>>> machine in question. After creating the keytab, what do you >>>>>> do >>>>>> with >>>>>> it? It jumps from creating the keytab to configuring Windows >>>>>> but >>>>>> does >>>>>> not say what to do with the keytab and the instructions never >>>>>> reference >>>>>> it again. Would someone please clarify this and is this >>>>>> something we >>>>>> would need to do for each and every Windows machine on our >>>>>> network? >>>>> Note that the ipa-getkeytab command is called with the -P >>>>> option, >>>>> so it >>>>> asks for a password: that password is used as a password for >>>>> the >>>>> machine principal and is stored in the directory. >>>>> >>>>> So no, the keytab is not really used anywhere else and can be >>>>> deleted. >>>>> It is the act of generating (with a known password) it that >>>>> needs >>>>> to be >>>>> done for every windows machine in the network. Please use >>>>> strong, >>>>> random and different passwords for each windows machine in the >>>>> network. >>>>> >>>>> >> > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > > -- > 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 From prasun.gera at gmail.com Wed Nov 11 04:30:47 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 10 Nov 2015 20:30:47 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> Message-ID: You are right in that the fullchain.pem doesn't have the root certificate. I ran "openssl x509 -in chain.pem -noout -text", and saw that it had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root certificate for DST Root CA X3 from https://www.identrust.com/certificates/trustid/root-download-x3.html, which is self signed from what I can tell. The issuer and the subject are the same. I added that to the fullchain, and the command seemed to work. However, it messed something up, and httpd didn't start after that. httpd error log had "Unable to verify certificate 'Signing-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved ". I added that to nss.conf, and ipactl started successfully after that. However, the webui hadn't configured the certificates properly. At this point, I just restored my backups of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to where things were earlier. I think it would be better to do these experiments on a test bed first. On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera wrote: > > > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale > wrote: > >> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote: >> > No it didn't quite work. >> > >> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/ >> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem >> > >> > which gives The full certificate chain is not present in >> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ >> > example.com/fullchain.pem >> > >> It looks like this error is triggered when there is no self-signed >> certificate in the trust chain (fullchain.pem). Could you confirm >> that this is the case, and if so, could you try appending the root >> certificate to fullchain.pem and trying again? >> >> > > I'm sorry, I didn't quite follow. Can you elaborate what I need to append > to what ? > > From let's encrypt's documentation: > > cert.pem > Server certificate only. > > This is what Apache needs for SSLCertificateFile. > > chain.pem > All certificates that need to be served by the browser excluding server > certificate, i.e. root and intermediate certificates only. > > This is what Apache needs for SSLCertificateChainFile. > > fullchain.pem > All certificates, including server certificate. This is concatenation of > chain.pem and cert.pem. > > This is what nginx needs for ssl_certificate. > > > So fullchain.pem should have all the relevant bits right ? Do you mean I > should append ipa's root cert from /etc/ipa/ca.crt ? > > > > > >> It may be that ipa-server-certinstall assumes that your server certs >> are signed by the same CA as your IPA CA certificate, which need not >> be the case. >> >> > >> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale >> > wrote: >> > >> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: >> > > > I tried using let's encrypt's certs manually, but I think I'm >> missing >> > > > something. Let's encrypt creates the following files : cert.pem >> > > chain.pem >> > > > fullchain.pem privkey.pem. I was trying to follow >> > > > >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> > > but i >> > > > wasn't able to get it to work. That page says, "The certificate in >> > > > mysite.crt must be signed by the CA used when installing FreeIPA." >> Since >> > > my >> > > > ipa installation uses the default internal CA, how do I get lets >> > > encrypt's >> > > > certs signed by the ipa CA ? Is that the missing step ? >> > > > >> > > I do not think that text is correct, in the case of a >> > > publicy-trusted certificate (i.e. the server cert is chained to a >> > > trusted issuer). >> > > >> > > Just ignore that text and follow the steps. Does it work? >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera >> > > wrote: >> > > > >> > > > > Thanks for the discussion. If someone can update the >> documentation with >> > > > > mozilla style old, intermediate and modern cipher lists for >> mod_nss, >> > > that >> > > > > would be great. Better still would be to add that option to the >> > > installer >> > > > > scripts so that you can choose it during installation. Integrating >> > > that in >> > > > > the package would also have the added benefit of settings >> remaining up >> > > to >> > > > > date without manual intervention as standards evolve. >> > > > > >> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale < >> ftweedal at redhat.com> >> > > > > wrote: >> > > > > >> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: >> > > > >> > Prasun Gera wrote: >> > > > >> > > Thanks. After the changes, most things seem to be in order. >> I see >> > > two >> > > > >> > > orange flags though: >> > > > >> > > >> > > > >> > > Secure Client-Initiated Renegotiation *Supported* >> *DoS >> > > > >> DANGER* (more >> > > > >> > > info >> > > > >> > > < >> > > > >> >> > > >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks >> > > > >> >) >> > > > >> > >> > > > >> > Renegotiation is required for the CA so you need to leave this >> > > enabled. >> > > > >> > >> > > > >> > > Session resumption (caching) *No (IDs assigned but not >> > > > >> accepted)* >> > > > >> > >> > > > >> > I'll need to look at this in more detail. At worst it would >> slow new >> > > > >> > connection performance slightly as it means every connection >> > > requires a >> > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. >> > > > >> > >> > > > >> Definitely not a show-stopper. The main reason this is an >> "orange" >> > > > >> alert in SSLLabs is because the server is assigning Session IDs >> but >> > > > >> then ignoring them; although confusing it is a fairly common >> default >> > > > >> behaviour and doesn't cause any issues with compliant client >> > > > >> implementation >> > > > >> >> > > > >> > rob >> > > > >> > >> > > > >> > > >> > > > >> > > Are these relevant/serious ? Can they be mitigated ? >> > > > >> > > >> > > > >> > > >> > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < >> > > rcritten at redhat.com >> > > > >> > > > wrote: >> > > > >> > > >> > > > >> > > Prasun Gera wrote: >> > > > >> > > > Yes, that's what I was planning to do. i.e. Convert >> cipher >> > > > >> names from >> > > > >> > > > SSL to NSS. I wasn't sure about the other settings >> though. >> > > Is >> > > > >> there an >> > > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? >> > > Similarly, >> > > > >> are there >> > > > >> > > > equivalent configs for HSTS on the mozilla page? Does >> NSS >> > > allow >> > > > >> using >> > > > >> > > > generated DH parameters instead of standard ones ? For >> SSL, >> > > the >> > > > >> > > > suggested modification to the config is >> 'SSLOpenSSLConfCmd >> > > > >> DHParameters >> > > > >> > > > "{path to dhparams.pem}"' after generating the params. >> > > > >> > > >> > > > >> > > NSS does not let the user specify cipher order. It uses >> its >> > > own >> > > > >> internal >> > > > >> > > sorting from strongest to weakest. >> > > > >> > > >> > > > >> > > HSTS is a header and not dependent upon SSL provider. >> > > > >> > > >> > > > >> > > mod_nss doesn't support DH ciphers. >> > > > >> > > >> > > > >> > > rob >> > > > >> > > >> > > > >> > > > >> > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < >> > > > >> ftweedal at redhat.com >> > > > >> > > > > ftweedal at redhat.com>>> >> > > > >> wrote: >> > > > >> > > > >> > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun >> Gera >> > > wrote: >> > > > >> > > > > Thanks for the ticket information. I would still >> be >> > > > >> interested in >> > > > >> > > > > configuring mod_nss properly (irrespective of >> whether >> > > the >> > > > >> certs are ipa >> > > > >> > > > > generated or 3rd party). These are the worrying >> notes >> > > > >> from ssllabs test: >> > > > >> > > > > >> > > > >> > > > > The server supports only older protocols, but >> not the >> > > > >> current best TLS 1.2. >> > > > >> > > > > Grade capped to C. >> > > > >> > > > > This server accepts the RC4 cipher, which is >> weak. >> > > Grade >> > > > >> capped to B. >> > > > >> > > > > The server does not support Forward Secrecy with >> the >> > > > >> reference browsers. >> > > > >> > > > > >> > > > >> > > > Use the "Modern" cipher suite[1] recommended by >> Mozilla >> > > as a >> > > > >> > > > starting point. See also the "Cipher names >> > > correspondence >> > > > >> table" on >> > > > >> > > > the same page for translating it to cipher names >> > > understood >> > > > >> by NSS >> > > > >> > > > to construct a valid setting for the >> `NSSCipherSuite' >> > > > >> directive. >> > > > >> > > > >> > > > >> > > > [1] >> > > > >> > > > >> > > > >> >> > > >> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility >> > > > >> > > > >> > > > >> > > > Cheers, >> > > > >> > > > Fraser >> > > > >> > > > >> > > > >> > > > > >> > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale >> > > > >> > > > >> > > > >> > > > >>> >> > > wrote: >> > > > >> > > > > >> > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, >> Prasun >> > > Gera >> > > > >> wrote: >> > > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the >> webui >> > > > >> > > accessible >> > > > >> > > > publicly. >> > > > >> > > > > > I'm >> > > > >> > > > > > > using a stock configuration which uses the >> certs >> > > > >> signed by >> > > > >> > > > ipa's CA for >> > > > >> > > > > > the >> > > > >> > > > > > > webui. This is mostly for convenience since >> it >> > > manages >> > > > >> > > renewals >> > > > >> > > > > > seamlessly. >> > > > >> > > > > > > This, however, requires users to add the CA >> as >> > > trusted >> > > > >> > > to their >> > > > >> > > > > > browsers. A >> > > > >> > > > > > > promising alternative to this is >> > > > >> https://letsencrypt.org/, >> > > > >> > > > which issues >> > > > >> > > > > > > browser trusted certs, and will manage auto >> > > renewals >> > > > >> too (in >> > > > >> > > > the future). >> > > > >> > > > > > > As a feature request, it would be nice to >> have >> > > closer >> > > > >> > > > integration between >> > > > >> > > > > > > ipa and the letsencrypt client which would >> make >> > > > >> managing >> > > > >> > > certs >> > > > >> > > > simple. >> > > > >> > > > > > I'm >> > > > >> > > > > > > about to set this up manually right now >> using the >> > > > >> > > external ssl >> > > > >> > > > certs >> > > > >> > > > > > guide. >> > > > >> > > > > > > >> > > > >> > > > > > Let's Encrypt is on our radar. I like the >> idea of >> > > being >> > > > >> > > able to >> > > > >> > > > > > install FreeIPA with publicly-trusted certs for >> > > HTTP and >> > > > >> > > LDAP from >> > > > >> > > > > > the beginning. This would require some work in >> > > > >> > > ipa-server-install >> > > > >> > > > > > in addition to certmonger support and a good, >> stable >> > > > >> Let's >> > > > >> > > Encrypt / >> > > > >> > > > > > ACME client implementation for Apache on >> Fedora. >> > > > >> > > > > > >> > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs >> is a >> > > > >> common >> > > > >> > > activity >> > > > >> > > > > > so I filed a ticket: >> > > > >> > > https://fedorahosted.org/freeipa/ticket/5431 >> > > > >> > > > > > >> > > > >> > > > > > Cheers, >> > > > >> > > > > > Fraser >> > > > >> > > > > > >> > > > >> > > > > > > Secondly, since the webui uses mod_nss, how >> would >> > > one >> > > > >> set it >> > > > >> > > > up to prefer >> > > > >> > > > > > > security over compatibility with older >> clients ? >> > > The >> > > > >> vast >> > > > >> > > > majority of >> > > > >> > > > > > > documentation online (for eg. >> > > > >> > > > > > > >> > > > >> > > > >> > > > >> > > >> > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) >> > > > >> is >> > > > >> > > > > > about >> > > > >> > > > > > > mod_ssl and I think the configuration doesn't >> > > transfer >> > > > >> > > directly to >> > > > >> > > > > > mod_nss. >> > > > >> > > > > > > Since this is the only web facing component, >> I >> > > would >> > > > >> like to >> > > > >> > > > set it up to >> > > > >> > > > > > > use stringent requirements. Right now, a >> test on >> > > > >> > > > > > > https://www.ssllabs.com/ssltest/ and >> > > > >> > > > https://weakdh.org/sysadmin.html >> > > > >> > > > > > > identifies >> > > > >> > > > > > > several issues. Since these things are not >> really >> > > my >> > > > >> area of >> > > > >> > > > expertise, I >> > > > >> > > > > > > would like some documentation regarding this. >> > > Also, >> > > > >> > > would manually >> > > > >> > > > > > > modifying any of the config files be >> overwritten >> > > by a >> > > > >> > > yum update ? >> > > > >> > > > > > >> > > > >> > > > > > > -- >> > > > >> > > > > > > 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 >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > >> > > > >> > >> > > > >> >> > > > > >> > > > > >> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Nov 11 05:35:33 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Nov 2015 15:35:33 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> Message-ID: <20151111053533.GH5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote: > You are right in that the fullchain.pem doesn't have the root certificate. > I ran "openssl x509 -in chain.pem -noout -text", and saw that it > had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject: > C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root > certificate for DST Root CA X3 from > https://www.identrust.com/certificates/trustid/root-download-x3.html, which > is self signed from what I can tell. The issuer and the subject are the > same. I added that to the fullchain, and the command seemed to work. > However, it messed something up, and httpd didn't start after that. httpd > error log had "Unable to verify certificate 'Signing-Cert'. Add > "NSSEnforceValidCerts off" to nss.conf so the server can start until the > problem can be resolved ". I added that to nss.conf, and ipactl started > successfully after that. However, the webui hadn't configured the > certificates properly. At this point, I just restored my backups > of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to > where things were earlier. I think it would be better to do these > experiments on a test bed first. > I am at a loss, and must have missed something. The purpose of this command is to be able to install 3rd party certificates, yet the code is expecting the certs to be signed by the IPA CA? Can someone explain what is going on here? Fraser > > On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera wrote: > > > > > > > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale > > wrote: > > > >> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote: > >> > No it didn't quite work. > >> > > >> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/ > >> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem > >> > > >> > which gives The full certificate chain is not present in > >> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ > >> > example.com/fullchain.pem > >> > > >> It looks like this error is triggered when there is no self-signed > >> certificate in the trust chain (fullchain.pem). Could you confirm > >> that this is the case, and if so, could you try appending the root > >> certificate to fullchain.pem and trying again? > >> > >> > > > > I'm sorry, I didn't quite follow. Can you elaborate what I need to append > > to what ? > > > > From let's encrypt's documentation: > > > > cert.pem > > Server certificate only. > > > > This is what Apache needs for SSLCertificateFile. > > > > chain.pem > > All certificates that need to be served by the browser excluding server > > certificate, i.e. root and intermediate certificates only. > > > > This is what Apache needs for SSLCertificateChainFile. > > > > fullchain.pem > > All certificates, including server certificate. This is concatenation of > > chain.pem and cert.pem. > > > > This is what nginx needs for ssl_certificate. > > > > > > So fullchain.pem should have all the relevant bits right ? Do you mean I > > should append ipa's root cert from /etc/ipa/ca.crt ? > > > > > > > > > > > >> It may be that ipa-server-certinstall assumes that your server certs > >> are signed by the same CA as your IPA CA certificate, which need not > >> be the case. > >> > >> > > >> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale > >> > wrote: > >> > > >> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: > >> > > > I tried using let's encrypt's certs manually, but I think I'm > >> missing > >> > > > something. Let's encrypt creates the following files : cert.pem > >> > > chain.pem > >> > > > fullchain.pem privkey.pem. I was trying to follow > >> > > > > >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > >> > > but i > >> > > > wasn't able to get it to work. That page says, "The certificate in > >> > > > mysite.crt must be signed by the CA used when installing FreeIPA." > >> Since > >> > > my > >> > > > ipa installation uses the default internal CA, how do I get lets > >> > > encrypt's > >> > > > certs signed by the ipa CA ? Is that the missing step ? > >> > > > > >> > > I do not think that text is correct, in the case of a > >> > > publicy-trusted certificate (i.e. the server cert is chained to a > >> > > trusted issuer). > >> > > > >> > > Just ignore that text and follow the steps. Does it work? > >> > > > >> > > Cheers, > >> > > Fraser > >> > > > >> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera > >> > > wrote: > >> > > > > >> > > > > Thanks for the discussion. If someone can update the > >> documentation with > >> > > > > mozilla style old, intermediate and modern cipher lists for > >> mod_nss, > >> > > that > >> > > > > would be great. Better still would be to add that option to the > >> > > installer > >> > > > > scripts so that you can choose it during installation. Integrating > >> > > that in > >> > > > > the package would also have the added benefit of settings > >> remaining up > >> > > to > >> > > > > date without manual intervention as standards evolve. > >> > > > > > >> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale < > >> ftweedal at redhat.com> > >> > > > > wrote: > >> > > > > > >> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > >> > > > >> > Prasun Gera wrote: > >> > > > >> > > Thanks. After the changes, most things seem to be in order. > >> I see > >> > > two > >> > > > >> > > orange flags though: > >> > > > >> > > > >> > > > >> > > Secure Client-Initiated Renegotiation *Supported* > >> *DoS > >> > > > >> DANGER* (more > >> > > > >> > > info > >> > > > >> > > < > >> > > > >> > >> > > > >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > >> > > > >> >) > >> > > > >> > > >> > > > >> > Renegotiation is required for the CA so you need to leave this > >> > > enabled. > >> > > > >> > > >> > > > >> > > Session resumption (caching) *No (IDs assigned but not > >> > > > >> accepted)* > >> > > > >> > > >> > > > >> > I'll need to look at this in more detail. At worst it would > >> slow new > >> > > > >> > connection performance slightly as it means every connection > >> > > requires a > >> > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. > >> > > > >> > > >> > > > >> Definitely not a show-stopper. The main reason this is an > >> "orange" > >> > > > >> alert in SSLLabs is because the server is assigning Session IDs > >> but > >> > > > >> then ignoring them; although confusing it is a fairly common > >> default > >> > > > >> behaviour and doesn't cause any issues with compliant client > >> > > > >> implementation > >> > > > >> > >> > > > >> > rob > >> > > > >> > > >> > > > >> > > > >> > > > >> > > Are these relevant/serious ? Can they be mitigated ? > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < > >> > > rcritten at redhat.com > >> > > > >> > > > wrote: > >> > > > >> > > > >> > > > >> > > Prasun Gera wrote: > >> > > > >> > > > Yes, that's what I was planning to do. i.e. Convert > >> cipher > >> > > > >> names from > >> > > > >> > > > SSL to NSS. I wasn't sure about the other settings > >> though. > >> > > Is > >> > > > >> there an > >> > > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? > >> > > Similarly, > >> > > > >> are there > >> > > > >> > > > equivalent configs for HSTS on the mozilla page? Does > >> NSS > >> > > allow > >> > > > >> using > >> > > > >> > > > generated DH parameters instead of standard ones ? For > >> SSL, > >> > > the > >> > > > >> > > > suggested modification to the config is > >> 'SSLOpenSSLConfCmd > >> > > > >> DHParameters > >> > > > >> > > > "{path to dhparams.pem}"' after generating the params. > >> > > > >> > > > >> > > > >> > > NSS does not let the user specify cipher order. It uses > >> its > >> > > own > >> > > > >> internal > >> > > > >> > > sorting from strongest to weakest. > >> > > > >> > > > >> > > > >> > > HSTS is a header and not dependent upon SSL provider. > >> > > > >> > > > >> > > > >> > > mod_nss doesn't support DH ciphers. > >> > > > >> > > > >> > > > >> > > rob > >> > > > >> > > > >> > > > >> > > > > >> > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > >> > > > >> ftweedal at redhat.com > >> > > > >> > > > >> ftweedal at redhat.com>>> > >> > > > >> wrote: > >> > > > >> > > > > >> > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun > >> Gera > >> > > wrote: > >> > > > >> > > > > Thanks for the ticket information. I would still > >> be > >> > > > >> interested in > >> > > > >> > > > > configuring mod_nss properly (irrespective of > >> whether > >> > > the > >> > > > >> certs are ipa > >> > > > >> > > > > generated or 3rd party). These are the worrying > >> notes > >> > > > >> from ssllabs test: > >> > > > >> > > > > > >> > > > >> > > > > The server supports only older protocols, but > >> not the > >> > > > >> current best TLS 1.2. > >> > > > >> > > > > Grade capped to C. > >> > > > >> > > > > This server accepts the RC4 cipher, which is > >> weak. > >> > > Grade > >> > > > >> capped to B. > >> > > > >> > > > > The server does not support Forward Secrecy with > >> the > >> > > > >> reference browsers. > >> > > > >> > > > > > >> > > > >> > > > Use the "Modern" cipher suite[1] recommended by > >> Mozilla > >> > > as a > >> > > > >> > > > starting point. See also the "Cipher names > >> > > correspondence > >> > > > >> table" on > >> > > > >> > > > the same page for translating it to cipher names > >> > > understood > >> > > > >> by NSS > >> > > > >> > > > to construct a valid setting for the > >> `NSSCipherSuite' > >> > > > >> directive. > >> > > > >> > > > > >> > > > >> > > > [1] > >> > > > >> > > > > >> > > > >> > >> > > > >> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > >> > > > >> > > > > >> > > > >> > > > Cheers, > >> > > > >> > > > Fraser > >> > > > >> > > > > >> > > > >> > > > > > >> > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > >> > > > >> > > > > >> > > > >> > > >> >>> > >> > > wrote: > >> > > > >> > > > > > >> > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, > >> Prasun > >> > > Gera > >> > > > >> wrote: > >> > > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the > >> webui > >> > > > >> > > accessible > >> > > > >> > > > publicly. > >> > > > >> > > > > > I'm > >> > > > >> > > > > > > using a stock configuration which uses the > >> certs > >> > > > >> signed by > >> > > > >> > > > ipa's CA for > >> > > > >> > > > > > the > >> > > > >> > > > > > > webui. This is mostly for convenience since > >> it > >> > > manages > >> > > > >> > > renewals > >> > > > >> > > > > > seamlessly. > >> > > > >> > > > > > > This, however, requires users to add the CA > >> as > >> > > trusted > >> > > > >> > > to their > >> > > > >> > > > > > browsers. A > >> > > > >> > > > > > > promising alternative to this is > >> > > > >> https://letsencrypt.org/, > >> > > > >> > > > which issues > >> > > > >> > > > > > > browser trusted certs, and will manage auto > >> > > renewals > >> > > > >> too (in > >> > > > >> > > > the future). > >> > > > >> > > > > > > As a feature request, it would be nice to > >> have > >> > > closer > >> > > > >> > > > integration between > >> > > > >> > > > > > > ipa and the letsencrypt client which would > >> make > >> > > > >> managing > >> > > > >> > > certs > >> > > > >> > > > simple. > >> > > > >> > > > > > I'm > >> > > > >> > > > > > > about to set this up manually right now > >> using the > >> > > > >> > > external ssl > >> > > > >> > > > certs > >> > > > >> > > > > > guide. > >> > > > >> > > > > > > > >> > > > >> > > > > > Let's Encrypt is on our radar. I like the > >> idea of > >> > > being > >> > > > >> > > able to > >> > > > >> > > > > > install FreeIPA with publicly-trusted certs for > >> > > HTTP and > >> > > > >> > > LDAP from > >> > > > >> > > > > > the beginning. This would require some work in > >> > > > >> > > ipa-server-install > >> > > > >> > > > > > in addition to certmonger support and a good, > >> stable > >> > > > >> Let's > >> > > > >> > > Encrypt / > >> > > > >> > > > > > ACME client implementation for Apache on > >> Fedora. > >> > > > >> > > > > > > >> > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs > >> is a > >> > > > >> common > >> > > > >> > > activity > >> > > > >> > > > > > so I filed a ticket: > >> > > > >> > > https://fedorahosted.org/freeipa/ticket/5431 > >> > > > >> > > > > > > >> > > > >> > > > > > Cheers, > >> > > > >> > > > > > Fraser > >> > > > >> > > > > > > >> > > > >> > > > > > > Secondly, since the webui uses mod_nss, how > >> would > >> > > one > >> > > > >> set it > >> > > > >> > > > up to prefer > >> > > > >> > > > > > > security over compatibility with older > >> clients ? > >> > > The > >> > > > >> vast > >> > > > >> > > > majority of > >> > > > >> > > > > > > documentation online (for eg. > >> > > > >> > > > > > > > >> > > > >> > > > > >> > > > >> > > > >> > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > >> > > > >> is > >> > > > >> > > > > > about > >> > > > >> > > > > > > mod_ssl and I think the configuration doesn't > >> > > transfer > >> > > > >> > > directly to > >> > > > >> > > > > > mod_nss. > >> > > > >> > > > > > > Since this is the only web facing component, > >> I > >> > > would > >> > > > >> like to > >> > > > >> > > > set it up to > >> > > > >> > > > > > > use stringent requirements. Right now, a > >> test on > >> > > > >> > > > > > > https://www.ssllabs.com/ssltest/ and > >> > > > >> > > > https://weakdh.org/sysadmin.html > >> > > > >> > > > > > > identifies > >> > > > >> > > > > > > several issues. Since these things are not > >> really > >> > > my > >> > > > >> area of > >> > > > >> > > > expertise, I > >> > > > >> > > > > > > would like some documentation regarding this. > >> > > Also, > >> > > > >> > > would manually > >> > > > >> > > > > > > modifying any of the config files be > >> overwritten > >> > > by a > >> > > > >> > > yum update ? > >> > > > >> > > > > > > >> > > > >> > > > > > > -- > >> > > > >> > > > > > > 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 > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > > >> > >> > > > > > >> > > > > > >> > > > >> > > > > From prasun.gera at gmail.com Wed Nov 11 01:19:44 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 10 Nov 2015 17:19:44 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> References: <20151105042122.GB20018@dhcp-40-8.bne.redhat.com> <563B6CF9.4020501@redhat.com> <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> Message-ID: On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale wrote: > On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote: > > No it didn't quite work. > > > > I ran ipa-server-certinstall -w /etc/letsencrypt/live/ > > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem > > > > which gives The full certificate chain is not present in > > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ > > example.com/fullchain.pem > > > It looks like this error is triggered when there is no self-signed > certificate in the trust chain (fullchain.pem). Could you confirm > that this is the case, and if so, could you try appending the root > certificate to fullchain.pem and trying again? > > I'm sorry, I didn't quite follow. Can you elaborate what I need to append to what ? >From let's encrypt's documentation: cert.pem Server certificate only. This is what Apache needs for SSLCertificateFile. chain.pem All certificates that need to be served by the browser excluding server certificate, i.e. root and intermediate certificates only. This is what Apache needs for SSLCertificateChainFile. fullchain.pem All certificates, including server certificate. This is concatenation of chain.pem and cert.pem. This is what nginx needs for ssl_certificate. So fullchain.pem should have all the relevant bits right ? Do you mean I should append ipa's root cert from /etc/ipa/ca.crt ? > It may be that ipa-server-certinstall assumes that your server certs > are signed by the same CA as your IPA CA certificate, which need not > be the case. > > > > > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale > > wrote: > > > > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: > > > > I tried using let's encrypt's certs manually, but I think I'm missing > > > > something. Let's encrypt creates the following files : cert.pem > > > chain.pem > > > > fullchain.pem privkey.pem. I was trying to follow > > > > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > > but i > > > > wasn't able to get it to work. That page says, "The certificate in > > > > mysite.crt must be signed by the CA used when installing FreeIPA." > Since > > > my > > > > ipa installation uses the default internal CA, how do I get lets > > > encrypt's > > > > certs signed by the ipa CA ? Is that the missing step ? > > > > > > > I do not think that text is correct, in the case of a > > > publicy-trusted certificate (i.e. the server cert is chained to a > > > trusted issuer). > > > > > > Just ignore that text and follow the steps. Does it work? > > > > > > Cheers, > > > Fraser > > > > > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera > > > wrote: > > > > > > > > > Thanks for the discussion. If someone can update the documentation > with > > > > > mozilla style old, intermediate and modern cipher lists for > mod_nss, > > > that > > > > > would be great. Better still would be to add that option to the > > > installer > > > > > scripts so that you can choose it during installation. Integrating > > > that in > > > > > the package would also have the added benefit of settings > remaining up > > > to > > > > > date without manual intervention as standards evolve. > > > > > > > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale < > ftweedal at redhat.com> > > > > > wrote: > > > > > > > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: > > > > >> > Prasun Gera wrote: > > > > >> > > Thanks. After the changes, most things seem to be in order. I > see > > > two > > > > >> > > orange flags though: > > > > >> > > > > > > >> > > Secure Client-Initiated Renegotiation *Supported* *DoS > > > > >> DANGER* (more > > > > >> > > info > > > > >> > > < > > > > >> > > > > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks > > > > >> >) > > > > >> > > > > > >> > Renegotiation is required for the CA so you need to leave this > > > enabled. > > > > >> > > > > > >> > > Session resumption (caching) *No (IDs assigned but not > > > > >> accepted)* > > > > >> > > > > > >> > I'll need to look at this in more detail. At worst it would > slow new > > > > >> > connection performance slightly as it means every connection > > > requires a > > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. > > > > >> > > > > > >> Definitely not a show-stopper. The main reason this is an > "orange" > > > > >> alert in SSLLabs is because the server is assigning Session IDs > but > > > > >> then ignoring them; although confusing it is a fairly common > default > > > > >> behaviour and doesn't cause any issues with compliant client > > > > >> implementation > > > > >> > > > > >> > rob > > > > >> > > > > > >> > > > > > > >> > > Are these relevant/serious ? Can they be mitigated ? > > > > >> > > > > > > >> > > > > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < > > > rcritten at redhat.com > > > > >> > > > wrote: > > > > >> > > > > > > >> > > Prasun Gera wrote: > > > > >> > > > Yes, that's what I was planning to do. i.e. Convert > cipher > > > > >> names from > > > > >> > > > SSL to NSS. I wasn't sure about the other settings > though. > > > Is > > > > >> there an > > > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? > > > Similarly, > > > > >> are there > > > > >> > > > equivalent configs for HSTS on the mozilla page? Does > NSS > > > allow > > > > >> using > > > > >> > > > generated DH parameters instead of standard ones ? For > SSL, > > > the > > > > >> > > > suggested modification to the config is > 'SSLOpenSSLConfCmd > > > > >> DHParameters > > > > >> > > > "{path to dhparams.pem}"' after generating the params. > > > > >> > > > > > > >> > > NSS does not let the user specify cipher order. It uses > its > > > own > > > > >> internal > > > > >> > > sorting from strongest to weakest. > > > > >> > > > > > > >> > > HSTS is a header and not dependent upon SSL provider. > > > > >> > > > > > > >> > > mod_nss doesn't support DH ciphers. > > > > >> > > > > > > >> > > rob > > > > >> > > > > > > >> > > > > > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < > > > > >> ftweedal at redhat.com > > > > >> > > > >>> > > > > >> wrote: > > > > >> > > > > > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun > Gera > > > wrote: > > > > >> > > > > Thanks for the ticket information. I would still > be > > > > >> interested in > > > > >> > > > > configuring mod_nss properly (irrespective of > whether > > > the > > > > >> certs are ipa > > > > >> > > > > generated or 3rd party). These are the worrying > notes > > > > >> from ssllabs test: > > > > >> > > > > > > > > >> > > > > The server supports only older protocols, but not > the > > > > >> current best TLS 1.2. > > > > >> > > > > Grade capped to C. > > > > >> > > > > This server accepts the RC4 cipher, which is weak. > > > Grade > > > > >> capped to B. > > > > >> > > > > The server does not support Forward Secrecy with > the > > > > >> reference browsers. > > > > >> > > > > > > > > >> > > > Use the "Modern" cipher suite[1] recommended by > Mozilla > > > as a > > > > >> > > > starting point. See also the "Cipher names > > > correspondence > > > > >> table" on > > > > >> > > > the same page for translating it to cipher names > > > understood > > > > >> by NSS > > > > >> > > > to construct a valid setting for the > `NSSCipherSuite' > > > > >> directive. > > > > >> > > > > > > > >> > > > [1] > > > > >> > > > > > > > >> > > > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility > > > > >> > > > > > > > >> > > > Cheers, > > > > >> > > > Fraser > > > > >> > > > > > > > >> > > > > > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > > > > >> > > > > > > > >> > > >>> > > > wrote: > > > > >> > > > > > > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun > > > Gera > > > > >> wrote: > > > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the > webui > > > > >> > > accessible > > > > >> > > > publicly. > > > > >> > > > > > I'm > > > > >> > > > > > > using a stock configuration which uses the > certs > > > > >> signed by > > > > >> > > > ipa's CA for > > > > >> > > > > > the > > > > >> > > > > > > webui. This is mostly for convenience since it > > > manages > > > > >> > > renewals > > > > >> > > > > > seamlessly. > > > > >> > > > > > > This, however, requires users to add the CA as > > > trusted > > > > >> > > to their > > > > >> > > > > > browsers. A > > > > >> > > > > > > promising alternative to this is > > > > >> https://letsencrypt.org/, > > > > >> > > > which issues > > > > >> > > > > > > browser trusted certs, and will manage auto > > > renewals > > > > >> too (in > > > > >> > > > the future). > > > > >> > > > > > > As a feature request, it would be nice to have > > > closer > > > > >> > > > integration between > > > > >> > > > > > > ipa and the letsencrypt client which would > make > > > > >> managing > > > > >> > > certs > > > > >> > > > simple. > > > > >> > > > > > I'm > > > > >> > > > > > > about to set this up manually right now using > the > > > > >> > > external ssl > > > > >> > > > certs > > > > >> > > > > > guide. > > > > >> > > > > > > > > > > >> > > > > > Let's Encrypt is on our radar. I like the idea > of > > > being > > > > >> > > able to > > > > >> > > > > > install FreeIPA with publicly-trusted certs for > > > HTTP and > > > > >> > > LDAP from > > > > >> > > > > > the beginning. This would require some work in > > > > >> > > ipa-server-install > > > > >> > > > > > in addition to certmonger support and a good, > stable > > > > >> Let's > > > > >> > > Encrypt / > > > > >> > > > > > ACME client implementation for Apache on Fedora. > > > > >> > > > > > > > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs > is a > > > > >> common > > > > >> > > activity > > > > >> > > > > > so I filed a ticket: > > > > >> > > https://fedorahosted.org/freeipa/ticket/5431 > > > > >> > > > > > > > > > >> > > > > > Cheers, > > > > >> > > > > > Fraser > > > > >> > > > > > > > > > >> > > > > > > Secondly, since the webui uses mod_nss, how > would > > > one > > > > >> set it > > > > >> > > > up to prefer > > > > >> > > > > > > security over compatibility with older > clients ? > > > The > > > > >> vast > > > > >> > > > majority of > > > > >> > > > > > > documentation online (for eg. > > > > >> > > > > > > > > > > >> > > > > > > > >> > > > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) > > > > >> is > > > > >> > > > > > about > > > > >> > > > > > > mod_ssl and I think the configuration doesn't > > > transfer > > > > >> > > directly to > > > > >> > > > > > mod_nss. > > > > >> > > > > > > Since this is the only web facing component, I > > > would > > > > >> like to > > > > >> > > > set it up to > > > > >> > > > > > > use stringent requirements. Right now, a test > on > > > > >> > > > > > > https://www.ssllabs.com/ssltest/ and > > > > >> > > > https://weakdh.org/sysadmin.html > > > > >> > > > > > > identifies > > > > >> > > > > > > several issues. Since these things are not > really > > > my > > > > >> area of > > > > >> > > > expertise, I > > > > >> > > > > > > would like some documentation regarding this. > > > Also, > > > > >> > > would manually > > > > >> > > > > > > modifying any of the config files be > overwritten > > > by a > > > > >> > > yum update ? > > > > >> > > > > > > > > > >> > > > > > > -- > > > > >> > > > > > > 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 > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Nov 11 07:57:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 11 Nov 2015 08:57:34 +0100 Subject: [Freeipa-users] Default shell for AD trust users In-Reply-To: <56423AFC.9040803@cora.nwra.com> References: <56423AFC.9040803@cora.nwra.com> Message-ID: <20151111075734.GB8838@hendrix.redhat.com> On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: > I see that AD trust users don't get their posix shell set: > > # getent passwd user > user at ad.nwra.com:*:2260345:2260345:A User:/export/home/user: > > I can fix this on the clients with override_shell, but that would apply to the > IPA domain users as well. Is there some way to configure this in the > trust/server? You might be interested in: https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir It's implemented in 7.2+ so any day now :) From mbabinsk at redhat.com Wed Nov 11 08:14:59 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 11 Nov 2015 09:14:59 +0100 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828C1BF@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> <56422342.2050600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BFA1@hqexdb01.hqfin! cen.gov> <56422893.9070703@redhat.com> <564228BC.3070900@redhat.com> <2909CC7109523F4BA968E7A201471B771828C066@hqexdb01.hqfincen! .gov> <564236AD.3030502@redhat.com> <2909CC7109523F4BA968E7A201471B771828C1BF@hqexdb01.hqfincen.gov> Message-ID: <5642F903.2060901@redhat.com> On 11/10/2015 08:14 PM, Gronde, Christopher (Contractor) wrote: > Removed the bad mapping. Krb5kdc service still will not start. Here is the access log. > > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory Team,cn=monitor" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid generator,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" scope=2 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=15 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=upgradedb,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=syntax validate,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=schema reload task,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=restore,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=index,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=import,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked attributes,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=export,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=backup,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember rebuild membership,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember map updates,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember export updates,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=abort cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Binary Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bit String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bitwise Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Boolean Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Exact String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Ignore String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Country String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Delivery Method Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Distinguished Name Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Enhanced Guide Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Facsimile Telephone Number Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Fax Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Generalized Time Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Guide Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Integer Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Internationalization Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=JPEG Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Name And Optional UID Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Numeric String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Octet String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=OID Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Postal Address Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Printable String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Space Insensitive String Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Telephone Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Teletex Terminal Identifier Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Telex Number Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=URI Syntax,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=CLEAR,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=CRYPT,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=MD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=NS-MTA-MD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SMD5,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Account Policy Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=attribute uniqueness,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=chaining database,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ldbm database,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvsearch)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=2 filter="(objectclass=vlvindex)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Linked Attributes,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=fixup linked attributes,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Managed Entries,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=MemberOf Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=PAM Pass Through Auth,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Pass Through Authentication,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=referential integrity postoperation,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Retro Changelog Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Schema Reload,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=schema reload task,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=State Change Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Syntax Validation Task,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=syntax validate,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=USN,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Views,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=0 filter="objectclass=*" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=32 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=7-bit check,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ACL Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config" scope=0 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=ACL Plugin,cn=plugins,cn=config" scope=0 filter="(objectclass=*)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=ACL preoperation,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Auto Membership Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember rebuild membership,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember export updates,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=automember map updates,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Class of Service,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="" scope=0 filter="(objectclass=*)" attrs="namingcontexts" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=config,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=deref,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=HTTP Client,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Multimaster Replication Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=abort cleanallruv,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Roles Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Legacy Replication Plugin,cn=plugins,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=import,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=export,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=backup,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=restore,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=index,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=upgradedb,cn=tasks,cn=config" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="dc=itmodev,dc=gov" > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=16 tag=48 nentries=0 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=1 filter="(objectclass=nsSaslMapping)" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=5 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=uid mapping,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 Hmmm the offending mapping is still there. Did you remove the entry using the steps Rob has posted before? (i.e. stop dirsrv, edit dse.ldif, start dirsrv and then start kdc) > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=Name Only,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=Full Principal,cn=mapping,cn=sasl,cn=config" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL > [10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 etime=0 > [10/Nov/2015:14:13:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 > [10/Nov/2015:14:13:04 -0500] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3 > [10/Nov/2015:14:13:04 -0500] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" > [10/Nov/2015:14:13:04 -0500] conn=1 op=1 SRCH base="cn=mapping,cn=sasl,cn=config" scope=2 filter="(objectClass=*)" attrs=ALL > [10/Nov/2015:14:13:04 -0500] conn=1 op=1 RESULT err=0 tag=101 nentries=6 etime=0 > [10/Nov/2015:14:13:04 -0500] conn=1 op=2 UNBIND > [10/Nov/2015:14:13:04 -0500] conn=1 op=2 fd=64 closed - U1 > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, November 10, 2015 1:26 PM > To: Gronde, Christopher (Contractor) ; Rich Megginson ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > Gronde, Christopher (Contractor) wrote: >> Is it possible to delete the mapping and try it and if it doesn't work or breaks something else add it back? How would I go about deleting this mapping? Or adding the mapping for principal name in the right order? >> > > So what I'd do is this: > > Do the same cn=mappping ldapsearch on the working master to see what the differences are. Determine if this is an ordering problem or if there is just extra gunk on this non-working master. > > And compare the versions of 389-ds: rpm -q 389-ds-base. They should be the same. If not then maybe one supports the new ordering and one doesn't. > > Then: > > 1. Stop dirsrv > 2. cp dse.ldif dse.ldif.mappings > 3. edit dse.ldif to match your findings. Either re-order the entries or remove ones you don't need (or both). > 4. Start dirsrv > 5. Start krb5kdc > > Step 1 is super important because 389-ds writes dse.ldif on shutdown so all changes made while the service is running will be lost. > > You can also do this via ldapmodify but it is far easier and less error prone to use your favorite editor in this case. > > rob > > -- Martin^3 Babinsky From harenberg at physik.uni-wuppertal.de Wed Nov 11 10:57:49 2015 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Wed, 11 Nov 2015 11:57:49 +0100 Subject: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 Message-ID: <56431F2D.5060404@physik.uni-wuppertal.de> Dear all, on our secondary IPA server (running 4.1.4) we did an upgrade of FC from 21 to 22, as 21 is running out of support. The upgrade process itself went smoothly, however, 386DS segfaults now: ns-slapd[1427]: segfault at 7fffe301413e ip 00007fffeeb1fa08 sp 00007fffffffd3d8 error 4 in libdb-5.3.so[7fffee9fa000+1b8000] every time it is started. This does not seem to be the problem reported earlier with IPA 4.2 on FC 23 (that segfaulted in libslapd). I couldn't get a hint out of the strace output. But the packages in question are: [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /lib64/libdb-5.3.so libdb-5.3.28-12.fc22.x86_64 [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /usr/sbin/ns-slapd 389-ds-base-1.3.4.4-1.fc22.x86_64 [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# Any hint is appreciated!!! Best regards Torsten -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> <> Bergische Universitaet <> <> FB C - Physik Tel.: +49 (0)202 439-3521 <> <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> <> 42097 Wuppertal <> <> <> <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> From bcoates at liquidweb.com Wed Nov 11 14:24:23 2015 From: bcoates at liquidweb.com (Branden Coates) Date: Wed, 11 Nov 2015 09:24:23 -0500 Subject: [Freeipa-users] Sudo Rules Help Message-ID: <56434F97.40405@liquidweb.com> I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) that I would greatly appreciate some help with. The core of the issue is that sudo rules fail to work when using ldap instead of ipa when you assign user groups and host groups to the sudo rule in place of explicitly adding users and hosts to the sudo rule. The reason for needing to use ldap over ipa is due to the organization requiring 2fa for all users via OTP tokens. We have a mix of cent 5 to 7 systems, not all can be immediately upgraded, so with cent 5 and 6 nodes ldap must be used instead of ipa to support 2fa. Explicitly assigning users and hosts to sudo rules is also unmanageable, the organization has hundreds of employees and multiple thousands of servers. Utilizing the host and user groups is a must. On cent 7 the default sssd.conf generated by FreeIPA works, 2fa works by default and the sssd.conf is using the ipa directives as well to parse user and host groups on sudo rules. Everything here works as expected. In cent 6 to allow 2fa to work the conf has to be updated to use ldap instead of ipa. In the process this seems to break the ability to search user and host groups on sudo rules. Users and hosts explicitly defined for the sudo rules still work so the clients can see the rules, they just do not seem to want to look within the groups that may be assigned to the rules. I moved the original sssd.conf created by FreeIPA using the ipa directives and sudo works as expected, but 2fa is not possible like this. Cent 5 is entirely incapable of using the sudo rules with user and host groups since sudo lacks sssd support in cent 5 and depends on /etc/ldap.conf to work. However like cent 6, users and hosts explicitly defined for the sudo rules still work, so I presume fixing the sudo rules with cent 6 on ldap would fix them here as well. Can anyone else confirm this behavior, and if so can anyone suggest any possible fixes or workarounds? I have attached the modified Cent6 and Cent 5 configs for sssd and ldap inline below(first time mailing, if inline is not ok please let me know what is preferable for future reference). Currently testing using the following versions: CentOS Linux release 7.1.1503 (Core) CentOS release 6.7 (Final) CentOS release 5.11 (Final) Cent 6 /etc/sssd/sssd.conf: #SSSD client configuration file. [domain/domain] id_provider = ldap auth_provider = ldap chpass_provider = ldap autofs_provider = ldap sudo_provider = ldap binddn = bindpw = scope = sub sudoers_base = ou=SUDOers,dc=,dc=com tls_cacertfile = /etc/ipa/ca.crt tls_checkpeer = yes tls_reqcert = demand ssl = start_tls ldap_schema = rfc2307bis ldap_uri = _srv_,ldap://.:389 ldap_search_base = dc=,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com ldap_sudo_search_base = ou=SUDOers,dc=,dc=com enumerate = True cache_credentials = True ldap_tls_cacertdir = /etc/ipa/ ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = demand ldap_id_use_start_tls = True krb5_realm = [sssd] services = nss, sudo, pam, ssh, autofs config_file_version = 2 domains = domain [nss] homedir_substring = /home filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd [pam] [sudo] [autofs] [ssh] [pac] [ifp] Cent 5 /etc/sssd/sssd.conf: #SSSD client configuration file. [domain/domain] id_provider = ldap auth_provider = ldap chpass_provider = ldap autofs_provider = ldap ldap_schema = rfc2307bis ldap_uri = _srv_,ldap://.:389 ldap_search_base = dc=,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com enumerate = True cache_credentials = True ldap_tls_cacertdir = /etc/ipa/ ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = demand ldap_id_use_start_tls = True krb5_realm = [sssd] services = nss, pam config_file_version = 2 domains = domain [nss] homedir_substring = /home filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd [pam] Cent 5 /etc/ldap.conf: #LDAP client configuration file. uri ldap://.:389 base dc=,dc=com ldap_version 3 tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes ssl start_tls binddn bindpw timelimit 5 bind_timelimit 15 sudoers_base ou=SUDOers,dc=,dc=com Thank you Brande -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver at doerr-privat.de Wed Nov 11 14:29:06 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Wed, 11 Nov 2015 15:29:06 +0100 Subject: [Freeipa-users] REST/JSON API: Howto add a user that is not expired Message-ID: <564350B2.4090206@doerr-privat.de> Hi, i'm still working with the JSON API and I now have the problem, that I want to add a user with a not expired password. I've tried setattr and addattr with the following JSON code, but both fail. {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","addattr":"krbpasswordexpiration=20160207010919Z","cn":"Oliver Support","sn":"Support"}],"id":0,"method":"user_add"} {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","cn":"Oliver Support","setattr":"krbpasswordexpiration=20160207010919Z","sn":"Support"}],"id":0,"method":"user_add"} The user is added to IPA, but the user is still forced to change it's password. In the response I could see that my krbpasswordexpiration is ignored. Any ideas what I'm doing wrong? Thanks Oliver From oliver at doerr-privat.de Wed Nov 11 14:57:26 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Wed, 11 Nov 2015 15:57:26 +0100 Subject: [Freeipa-users] REST/JSON API: Howto add a user that is not expired In-Reply-To: <564350B2.4090206@doerr-privat.de> References: <564350B2.4090206@doerr-privat.de> Message-ID: <56435756.1030404@doerr-privat.de> Hi, i've tried user_mod instead because of https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html and got Error-code: 2100 Error-name: ACIError Error-msg: Insufficient access: Insufficient 'write' privilege to the 'krbPasswordExpiration' attribute of entry 'uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de'. Inside the acces log of the LDAP Server I could see... [09/Nov/2015:18:40:31 +0100] conn=658 op=7 MOD dn="uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de" [09/Nov/2015:18:40:31 +0100] conn=658 op=7 RESULT err=50 tag=103 nentries=0 etime=0 So it looks like it is a permission issue. But I still have the problem when use admin to do the job. Any idea about how to change the permission or an API that it is able to do the job? Thanks in advance Oliver Am 11.11.2015 um 15:29 schrieb Oliver D?rr: > Hi, > > i'm still working with the JSON API and I now have the problem, that I > want to add a user with a not expired password. I've tried setattr and > addattr with the following JSON code, but both fail. > {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","addattr":"krbpasswordexpiration=20160207010919Z","cn":"Oliver > Support","sn":"Support"}],"id":0,"method":"user_add"} > > > {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","cn":"Oliver > Support","setattr":"krbpasswordexpiration=20160207010919Z","sn":"Support"}],"id":0,"method":"user_add"} > > > > The user is added to IPA, but the user is still forced to change it's > password. In the response I could see that my krbpasswordexpiration > is ignored. > > Any ideas what I'm doing wrong? > > Thanks > Oliver > From abokovoy at redhat.com Wed Nov 11 15:13:14 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Nov 2015 17:13:14 +0200 Subject: [Freeipa-users] REST/JSON API: Howto add a user that is not expired In-Reply-To: <56435756.1030404@doerr-privat.de> References: <564350B2.4090206@doerr-privat.de> <56435756.1030404@doerr-privat.de> Message-ID: <20151111151314.GF1147@redhat.com> On Wed, 11 Nov 2015, Oliver D?rr wrote: >Hi, > >i've tried user_mod instead because of https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html >and got > >Error-code: 2100 >Error-name: ACIError >Error-msg: Insufficient access: Insufficient 'write' privilege to >the 'krbPasswordExpiration' attribute of entry >'uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de'. > >Inside the acces log of the LDAP Server I could see... > >[09/Nov/2015:18:40:31 +0100] conn=658 op=7 MOD >dn="uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de" >[09/Nov/2015:18:40:31 +0100] conn=658 op=7 RESULT err=50 tag=103 >nentries=0 etime=0 > >So it looks like it is a permission issue. But I still have the >problem when use admin to do the job. Any idea about how to change the >permission or an API that it is able to do the job? You simply cannot make it working for cases when a password change coming from a non-user. This is intentional. See http://www.freeipa.org/page/New_Passwords_Expired You can do double change via LDAP password change (or Kerberos) where you changre a password first to something temporary, then try to change it again as a user with that temporary password and set a new one. Since the second change would be done as a user, that should allow the change to happen without raising a flag. > >Thanks in advance >Oliver > >Am 11.11.2015 um 15:29 schrieb Oliver D?rr: >>Hi, >> >>i'm still working with the JSON API and I now have the problem, that >>I want to add a user with a not expired password. I've tried setattr >>and addattr with the following JSON code, but both fail. >>{"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","addattr":"krbpasswordexpiration=20160207010919Z","cn":"Oliver >>Support","sn":"Support"}],"id":0,"method":"user_add"} >> >> >>{"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","cn":"Oliver Support","setattr":"krbpasswordexpiration=20160207010919Z","sn":"Support"}],"id":0,"method":"user_add"} >> >> >> >>The user is added to IPA, but the user is still forced to change >>it's password. In the response I could see that my >>krbpasswordexpiration is ignored. >> >>Any ideas what I'm doing wrong? >> >>Thanks >>Oliver >> > >-- >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 -- / Alexander Bokovoy From andrew.krause at breakthroughfuel.com Wed Nov 11 15:20:21 2015 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Wed, 11 Nov 2015 15:20:21 +0000 Subject: [Freeipa-users] 3/4 replica failure - unknown reasons why Message-ID: <9789D1C1-572F-4CB7-AE8D-26E07E94B1CB@breakthroughfuel.com> Yesterday I came in to 3 of my 4 freeipa replicas in an unusable state and replication was not connecting any of the hosts to each other. My first/primary host was still servicing authentication requests, but the others were in varying states of usability. I?ve investigated logs on all 4 nodes and the only thing I can see is messages like this from when the problem started until I restarted all 4 with ipactl stop/ipactl start: [09/Nov/2015:19:17:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:19:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:21:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:23:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:25:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:27:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:29:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:31:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:32:37 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Warning: Attempting to release replica, but unable to receive endReplication extended operation response from the replica. Error -5 (Timed out) [09/Nov/2015:19:33:29 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:34:37 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:35:28 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. [09/Nov/2015:19:36:41 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. We?ve already looked into our network and there was no outage/interruption between sites during the timeframe in question. The only corrective action that was taken was to restart each node. Does anyone know any way I can investigate further what caused this issue? I don?t like giving ?I don?t know? answers for why replication stopped working and did not resume by itself. From mbasti at redhat.com Wed Nov 11 15:26:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 16:26:53 +0100 Subject: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 In-Reply-To: <56431F2D.5060404@physik.uni-wuppertal.de> References: <56431F2D.5060404@physik.uni-wuppertal.de> Message-ID: <56435E3D.4060605@redhat.com> On 11.11.2015 11:57, Torsten Harenberg wrote: > Dear all, > > on our secondary IPA server (running 4.1.4) we did an upgrade of FC from > 21 to 22, as 21 is running out of support. > > The upgrade process itself went smoothly, however, 386DS segfaults now: > > ns-slapd[1427]: segfault at 7fffe301413e ip 00007fffeeb1fa08 sp > 00007fffffffd3d8 error 4 in libdb-5.3.so[7fffee9fa000+1b8000] > > every time it is started. > > This does not seem to be the problem reported earlier with IPA 4.2 on FC > 23 (that segfaulted in libslapd). > > I couldn't get a hint out of the strace output. But the packages in > question are: > > [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /lib64/libdb-5.3.so > libdb-5.3.28-12.fc22.x86_64 > [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /usr/sbin/ns-slapd > 389-ds-base-1.3.4.4-1.fc22.x86_64 > [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# > > > Any hint is appreciated!!! > > Best regards > > Torsten > Hello, can you provide traceback? http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes Martin From rcritten at redhat.com Wed Nov 11 16:33:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Nov 2015 11:33:18 -0500 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <20151111053533.GH5336@dhcp-40-8.bne.redhat.com> References: <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> <20151111053533.GH5336@dhcp-40-8.bne.redhat.com> Message-ID: <56436DCE.2080204@redhat.com> Fraser Tweedale wrote: > On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote: >> You are right in that the fullchain.pem doesn't have the root certificate. >> I ran "openssl x509 -in chain.pem -noout -text", and saw that it >> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject: >> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root >> certificate for DST Root CA X3 from >> https://www.identrust.com/certificates/trustid/root-download-x3.html, which >> is self signed from what I can tell. The issuer and the subject are the >> same. I added that to the fullchain, and the command seemed to work. >> However, it messed something up, and httpd didn't start after that. httpd >> error log had "Unable to verify certificate 'Signing-Cert'. Add >> "NSSEnforceValidCerts off" to nss.conf so the server can start until the >> problem can be resolved ". I added that to nss.conf, and ipactl started >> successfully after that. However, the webui hadn't configured the >> certificates properly. At this point, I just restored my backups >> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to >> where things were earlier. I think it would be better to do these >> experiments on a test bed first. >> > I am at a loss, and must have missed something. The purpose of this > command is to be able to install 3rd party certificates, yet the > code is expecting the certs to be signed by the IPA CA? > > Can someone explain what is going on here? That isn't the problem. It doesn't require the IPA CA at all. It just checks that the root CA which issued the server cert is available (looks for subject == issuer). It would appear that something wasn't imported into the Apache NSS db. You'd need to re-run the import and then look at the Apache NSS database to ensure that the entire cert chain was imported with the proper trust which apparently it wasn't. # certutil -L -d /etc/httpd/alias The entire chain should be there, probably with trust like CT,, or C,,. To fix trust: # certutil -M -n "" -t CT,, -d /etc/httpd/alias To add missing certs: # certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i /path/to/pem Validate the web server cert. Use whatever nickname is appropriate for you: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias The more details you have on what you did to fix this the better as that can be used to generate a new bug to fix this upstream. rob From orion at cora.nwra.com Wed Nov 11 18:36:29 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 11 Nov 2015 11:36:29 -0700 Subject: [Freeipa-users] Default shell for AD trust users In-Reply-To: <20151111075734.GB8838@hendrix.redhat.com> References: <56423AFC.9040803@cora.nwra.com> <20151111075734.GB8838@hendrix.redhat.com> Message-ID: <56438AAD.70006@cora.nwra.com> On 11/11/2015 12:57 AM, Jakub Hrozek wrote: > On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: >> I see that AD trust users don't get their posix shell set: >> >> # getent passwd user >> user at ad.nwra.com:*:2260345:2260345:A User:/export/home/user: >> >> I can fix this on the clients with override_shell, but that would apply to the >> IPA domain users as well. Is there some way to configure this in the >> trust/server? > > You might be interested in: > https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir > > It's implemented in 7.2+ so any day now :) > Thanks for that, although I think default_shell = /bin/bash should work for me now. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Wed Nov 11 18:37:47 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 11 Nov 2015 11:37:47 -0700 Subject: [Freeipa-users] Default shell for AD trust users In-Reply-To: <20151111075734.GB8838@hendrix.redhat.com> References: <56423AFC.9040803@cora.nwra.com> <20151111075734.GB8838@hendrix.redhat.com> Message-ID: <56438AFB.6070404@cora.nwra.com> On 11/11/2015 12:57 AM, Jakub Hrozek wrote: > On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: >> I see that AD trust users don't get their posix shell set: >> >> # getent passwd user >> user at ad.nwra.com:*:2260345:2260345:A User:/export/home/user: >> >> I can fix this on the clients with override_shell, but that would apply to the >> IPA domain users as well. Is there some way to configure this in the >> trust/server? > > You might be interested in: > https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir > > It's implemented in 7.2+ so any day now :) > Um, that's for homedir right, not the shell? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jhrozek at redhat.com Wed Nov 11 19:42:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 11 Nov 2015 20:42:46 +0100 Subject: [Freeipa-users] Default shell for AD trust users In-Reply-To: <56438AFB.6070404@cora.nwra.com> References: <56423AFC.9040803@cora.nwra.com> <20151111075734.GB8838@hendrix.redhat.com> <56438AFB.6070404@cora.nwra.com> Message-ID: <20151111194246.GQ21503@hendrix.redhat.com> On Wed, Nov 11, 2015 at 11:37:47AM -0700, Orion Poplawski wrote: > On 11/11/2015 12:57 AM, Jakub Hrozek wrote: > > On Tue, Nov 10, 2015 at 11:44:12AM -0700, Orion Poplawski wrote: > >> I see that AD trust users don't get their posix shell set: > >> > >> # getent passwd user > >> user at ad.nwra.com:*:2260345:2260345:A User:/export/home/user: > >> > >> I can fix this on the clients with override_shell, but that would apply to the > >> IPA domain users as well. Is there some way to configure this in the > >> trust/server? > > > > You might be interested in: > > https://fedorahosted.org/sssd/wiki/DesignDocs/use_AD_homedir > > > > It's implemented in 7.2+ so any day now :) > > > > Um, that's for homedir right, not the shell? Ah, yes, sorry. I don't know why I read homedir and not shell. Shell should already be transferred with IPA 4.x, but you can always use fallback_shell. From mkosek at redhat.com Wed Nov 11 20:22:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Nov 2015 21:22:18 +0100 Subject: [Freeipa-users] ipa-getkeytab missing permissions after migration In-Reply-To: <5641F851.1070908@mittwald.de> References: <5641F851.1070908@mittwald.de> Message-ID: <5643A37A.7070203@redhat.com> On 11/10/2015 02:59 PM, Dominik Korittki wrote: > > Hello folks, > > I created a replica IPA host with version 4.1.0-18.el7.centos.4, > while the initial master is a FreeIPA 3.3.3. > > Everything seems to work fine with the new host except for one thing: > We have a special IPA user, which has the rights for managing and enrolling hosts. > I am able to add hosts with this user, but ipa-getkeytab command returns the > following message: > > root at ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p "host/testhost.internal" > -k testhost.internal.keytab > Failed to parse result: Insufficient access rights > > The keytab was successfully created, though. dirsrv error logs showed me this > after raising log level: > > [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=590 op=3 > binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" > [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny write on > entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys) > to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the > subject by aci(53): aciname= "Entities are allowed to rekey managed entries", > acidn="cn=accounts,dc=internal" > [10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file ipa_pwd_extop.c, > line 756]: slapi_access_allowed does not allow WRITE to > ipaProtectedOperation;write_keys! > [10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, line > 1630]: Not allowed to set keytab on [host/testhost.internal at INTERNAL]! > [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3 > binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" > [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow write on > entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) > to uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by aci(277): > aciname= "permission:System: Manage Host Keytab", > acidn="cn=computers,cn=accounts,dc=internal" > > > So it seems he can't find a proper write permission for > ipaProtectedOperation;write_keys. > When creating a permission with write access to this attribute everything works > fine, but should'nt there > already be a proper permission? I discovered the following permission: > > root at ipa01:~ > ipa permission-show --all --raw 'System: Manage Host Keytab > Permissions' > dn: cn=System: Manage Host Keytab > Permissions,cn=permissions,cn=pbac,dc=internal > cn: System: Manage Host Keytab Permissions > ipapermright: write > ipapermright: read > ipapermright: compare > ipapermright: search > ipapermincludedattr: createtimestamp > ipapermincludedattr: modifytimestamp > ipapermincludedattr: entryusn > ipapermdefaultattr: objectclass > ipapermdefaultattr: ipaallowedtoperform;write_keys > ipapermdefaultattr: ipaallowedtoperform;read_keys > ipapermbindruletype: permission > ipapermlocation: cn=computers,cn=accounts,dc=internal > ipapermtargetfilter: (objectclass=ipahost) > member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal > aci: (targetattr = "createtimestamp || entryusn || > ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || > modifytimestamp || objectclass")(targetfilter = > "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab > Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: > Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=internal";) > ipapermissiontype: V2 > ipapermissiontype: MANAGED > ipapermissiontype: SYSTEM > memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal > memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal > memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal > objectclass: ipapermission > objectclass: top > objectclass: groupofnames > objectclass: ipapermissionv2 > > > So there is a aci with write access on ipaallowedtoperform;write_keys, > but not on ipaProtectedOperation;write_keys. > > So the question is: Has something gone wrong while migrating the aci's to > freeipa v4 style? > If yes, how can I fix it? JFTR, the design for this new attribute is here: http://www.freeipa.org/page/V4/Keytab_Retrieval Looking at the ACIs for ipaProtectedOperation, I see following: dn: cn=accounts,$SUFFIX add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl "Users allowed to retrieve keytab keys"; allow(read) userattr="ipaAllowedToPerform;read_keys#USERDN";) add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl "Groups allowed to retrieve keytab keys"; allow(read) userattr="ipaAllowedToPerform;read_keys#GROUPDN";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Users allowed to create keytab keys"; allow(write) userattr="ipaAllowedToPerform;write_keys#USERDN";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Groups allowed to create keytab keys"; allow(write) userattr="ipaAllowedToPerform;write_keys#GROUPDN";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) userdn="ldap:///self";) add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";) That means that hosts and services can write their own keys, or principals in ipaAllowedToPerform;operation can do the operation, or hosts/services in managedBy attribute can do write. For general keytab write access, we have the old style permission/ACI "System: Manage Host Keytab". I tested it and it works: # ipa permission-show "System: Manage Host Keytab" Permission name: System: Manage Host Keytab Granted rights: write Effective attributes: krblastpwdchange, krbprincipalkey Default attributes: krbprincipalkey, krblastpwdchange Bind rule type: permission Subtree: cn=computers,cn=accounts,dc=rhel72 Type: host Granted to Privilege: Host Enrollment, Host Administrators, fbar Indirect Member of roles: fbar, IT Specialist # ipa user-show fbar --all --raw dn: uid=fbar,cn=users,cn=accounts,dc=rhel72 ... memberof: cn=fbar,cn=roles,cn=accounts,dc=rhel72 memberof: cn=ipausers,cn=groups,cn=accounts,dc=rhel72 memberofindirect: cn=fbar,cn=privileges,cn=pbac,dc=rhel72 memberofindirect: cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=rhel72 ... # kinit fbar # ipa-getkeytab -s `hostname` -k /tmp/fbar.keytab -p host/fbar.example.com Failed to parse result: Insufficient access rights Retrying with pre-4.0 keytab retrieval method... Keytab successfully retrieved and stored in: /tmp/fbar.keytab The keytab was created, but I wonder if this is expected and the I wonder if this is expected and "System: Manage Host Keytab: should not rather operate with ipaProtectedOperation. CCing Simo. From mkosek at redhat.com Wed Nov 11 20:24:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Nov 2015 21:24:49 +0100 Subject: [Freeipa-users] mastercrl files In-Reply-To: <20151110215920.GE5336@dhcp-40-8.bne.redhat.com> References: <20151110215920.GE5336@dhcp-40-8.bne.redhat.com> Message-ID: <5643A411.6070009@redhat.com> On 11/10/2015 10:59 PM, Fraser Tweedale wrote: > On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote: >> hi, >> >> do we need to keep all the MasterCRL-YYYYMMDD-HHMMSS.der files or can we >> purge them on a regular basis (say, keep 60 days dump the rest)? >> >> $ ls -l | wc -l >> 3621 >> >> this is in a server installed 3 years ago. >> >> -- >> Groeten, >> natxo >> > Hi Natxo, > > You can purge them. I am not sure why we keep the old ones around; > can someone fill me in? This was not touched loong ago. CCing Rob in case he has an idea, but if not - you are probably the best person to improve it :-) From rcritten at redhat.com Wed Nov 11 20:41:34 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Nov 2015 15:41:34 -0500 Subject: [Freeipa-users] mastercrl files In-Reply-To: <5643A411.6070009@redhat.com> References: <20151110215920.GE5336@dhcp-40-8.bne.redhat.com> <5643A411.6070009@redhat.com> Message-ID: <5643A7FE.6010605@redhat.com> Martin Kosek wrote: > On 11/10/2015 10:59 PM, Fraser Tweedale wrote: >> On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote: >>> hi, >>> >>> do we need to keep all the MasterCRL-YYYYMMDD-HHMMSS.der files or can we >>> purge them on a regular basis (say, keep 60 days dump the rest)? >>> >>> $ ls -l | wc -l >>> 3621 >>> >>> this is in a server installed 3 years ago. >>> >>> -- >>> Groeten, >>> natxo >>> >> Hi Natxo, >> >> You can purge them. I am not sure why we keep the old ones around; >> can someone fill me in? > > This was not touched loong ago. CCing Rob in case he has an idea, but if > not - you are probably the best person to improve it :-) > I don't know if I considered this at all back in the day but I agree it is probably up to dogtag to prune this directory. The files to keep should be based on the generation schedule. I can't think of any value an older CRL might provide though perhaps that should be configurable too. rob From mexigabacho at gmail.com Wed Nov 11 22:02:59 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Wed, 11 Nov 2015 17:02:59 -0500 Subject: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1 Message-ID: Do we know what the status of getting these packages prepped and into the mainstream repos (like EPEL, I suppose)? I'm just curious as I try and keep my repos minimal on servers (for obvious reasons), but I would really like to begin testing/using the functionality in 4.2. Thanks as always! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Nov 11 22:50:20 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 11 Nov 2015 14:50:20 -0800 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: <56436DCE.2080204@redhat.com> References: <563C3210.40600@redhat.com> <20151106052317.GA31495@dhcp-40-8.bne.redhat.com> <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> <20151111053533.GH5336@dhcp-40-8.bne.redhat.com> <56436DCE.2080204@redhat.com> Message-ID: I'll try this on an aws instance and report. Some googling also suggests that the additional step of "pk12util -i ipa.example.com.p12 -d /etc/httpd/alias" is needed, which is similar to what you suggested. A few more questions: 1) How would renewals work ? the pem files can be renewed on expiration from LE's client. Would I need to run the exact same steps every time ? 2) Do expired ones need to be removed from the db in some way before renewed ones can be added ? 3) If httpd's certs expire, it won't affect any other functionality apart from the webui right ? Are there any other side effects ? I won't be using this for ldap certs. 4) How would I revert to IPA signed certs with automatic renewal if I want to ? i.e. Reverting to stock configuration On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden wrote: > Fraser Tweedale wrote: > >> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote: >> >>> You are right in that the fullchain.pem doesn't have the root >>> certificate. >>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it >>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and >>> Subject: >>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root >>> certificate for DST Root CA X3 from >>> https://www.identrust.com/certificates/trustid/root-download-x3.html, >>> which >>> is self signed from what I can tell. The issuer and the subject are the >>> same. I added that to the fullchain, and the command seemed to work. >>> However, it messed something up, and httpd didn't start after that. httpd >>> error log had "Unable to verify certificate 'Signing-Cert'. Add >>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the >>> problem can be resolved ". I added that to nss.conf, and ipactl started >>> successfully after that. However, the webui hadn't configured the >>> certificates properly. At this point, I just restored my backups >>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to >>> where things were earlier. I think it would be better to do these >>> experiments on a test bed first. >>> >>> I am at a loss, and must have missed something. The purpose of this >> command is to be able to install 3rd party certificates, yet the >> code is expecting the certs to be signed by the IPA CA? >> >> Can someone explain what is going on here? >> > > That isn't the problem. It doesn't require the IPA CA at all. It just > checks that the root CA which issued the server cert is available (looks > for subject == issuer). It would appear that something wasn't imported into > the Apache NSS db. > > You'd need to re-run the import and then look at the Apache NSS database > to ensure that the entire cert chain was imported with the proper trust > which apparently it wasn't. > > # certutil -L -d /etc/httpd/alias > > The entire chain should be there, probably with trust like CT,, or C,,. > > To fix trust: > > # certutil -M -n "" -t CT,, -d /etc/httpd/alias > > To add missing certs: > > # certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i > /path/to/pem > > Validate the web server cert. Use whatever nickname is appropriate for you: > > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias > > The more details you have on what you did to fix this the better as that > can be used to generate a new bug to fix this upstream. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Wed Nov 11 21:26:11 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Wed, 11 Nov 2015 22:26:11 +0100 Subject: [Freeipa-users] SSO Git http smart server and freeipa group authentication In-Reply-To: <563FD2D7.8040102@redhat.com> References: <563FD2D7.8040102@redhat.com> Message-ID: Thanks Simo & Fraser, Creating a .netrc file on the client computer with according to the SO postings with below content made things work perfectly! machine gitserver.my.lan username '' password '' machine gitserver username '' password '' I would like to use TLS and I've made it work by turning off ssl validation in git: git config --global http.sslVerify false If I would like to use ssl validation, is there some way to use a certificate for the CNAME? Seems I can only add certificate (at least from the UI) for a valid principal? (I'm using freeipa-server 4.2.3 on F23) Regards, -- john 2015-11-08 23:55 GMT+01:00 Simo Sorce : > On 08/11/15 08:07, John Obaterspok wrote: > >> Hello, >> >> Anyone got git-http-backend working with freeipa group auhentication and >> would like to share their apache .conf file? >> >> >> I've tried this on the IPA server with a dummy git repository setup in >> /opt/gitrepos/test1.git >> gitserver.my.lan is a CNAME for ipaserver.my.lan >> >> First, "git clone http://gitserver.my.lan/test1.git" prompts (even >> though I >> have a ticket) for user+pwd but still fails. >> >> Any suggestions are welcome! >> >> -- john >> >> >> >> >> DocumentRoot /opt/gitrepos >> >> # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?' >> # restorecon -R -v /opt/gitrepos >> >> SetEnv GIT_PROJECT_ROOT /opt/gitrepos >> SetEnv GIT_HTTP_EXPORT_ALL >> SetEnv REMOTE_USER $REDIRECT_REMOTE_USER >> ScriptAlias / /usr/libexec/git-core/git-http-backend/ >> ServerName gitserver.my.lan >> >> >> Options Indexes >> AllowOverride None >> Require all granted >> >> >> >> Options Indexes >> AllowOverride None >> Require all granted >> >> >> >> AuthType Kerberos >> AuthName "Kerberos Login" >> KrbAuthRealm MY.LAN >> Krb5KeyTab /etc/httpd/conf/ipa.keytab >> KrbMethodNegotiate on >> KrbMethodK5Passwd off >> KrbSaveCredentials on >> KrbVerifyKDC on >> KrbServiceName HTTP >> >> AuthLDAPUrl >> ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName >> Require ldap-group cn=ipausers,dc=my,dc=lan >> > > This should probably be somehting like: > cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan > > Although you should probably create a git specific group, especially if > you want it to be a posix group that can own files (ipausers is not a posix > group and we are actually trying to phase it out) > > Also you are not doing LDAP authentication, you only want to do > authorization, and for that you may want to actually use nsswitch based > authorization which can be cached by sssd and not a query out to LDAP for > each connection. > Unfortunately the basic Apache modules do not support system group > authentication directly, so what you may do instead is to have a cron job > that do the following: > getent group git-users | cut -d: -f1,4 |tr ',' ' ' > /my/authorization/file > > And in apache have set the following directives instead of the above two: > AuthGroupFile /my/authorization/file > Require group git-users > > HTH, > Simo > > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Nov 12 00:14:42 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 12 Nov 2015 10:14:42 +1000 Subject: [Freeipa-users] mastercrl files In-Reply-To: <5643A7FE.6010605@redhat.com> References: <20151110215920.GE5336@dhcp-40-8.bne.redhat.com> <5643A411.6070009@redhat.com> <5643A7FE.6010605@redhat.com> Message-ID: <20151112001442.GO5336@dhcp-40-8.bne.redhat.com> On Wed, Nov 11, 2015 at 03:41:34PM -0500, Rob Crittenden wrote: > Martin Kosek wrote: > >On 11/10/2015 10:59 PM, Fraser Tweedale wrote: > >>On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote: > >>>hi, > >>> > >>>do we need to keep all the MasterCRL-YYYYMMDD-HHMMSS.der files or can we > >>>purge them on a regular basis (say, keep 60 days dump the rest)? > >>> > >>>$ ls -l | wc -l > >>>3621 > >>> > >>>this is in a server installed 3 years ago. > >>> > >>>-- > >>>Groeten, > >>>natxo > >>> > >>Hi Natxo, > >> > >>You can purge them. I am not sure why we keep the old ones around; > >>can someone fill me in? > > > >This was not touched loong ago. CCing Rob in case he has an idea, but if > >not - you are probably the best person to improve it :-) > > > > I don't know if I considered this at all back in the day but I agree it is > probably up to dogtag to prune this directory. The files to keep should be > based on the generation schedule. I can't think of any value an older CRL > might provide though perhaps that should be configurable too. > > rob > I filed tickets: https://fedorahosted.org/pki/ticket/1696 https://fedorahosted.org/freeipa/ticket/5447 I do not think it is a high priority because it can be achieved with a simple cron job. But we should change the default behaviour eventually. Cheers, Fraser From ftweedal at redhat.com Thu Nov 12 01:12:28 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 12 Nov 2015 11:12:28 +1000 Subject: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl In-Reply-To: References: <20151110233158.GF5336@dhcp-40-8.bne.redhat.com> <20151111010433.GG5336@dhcp-40-8.bne.redhat.com> <20151111053533.GH5336@dhcp-40-8.bne.redhat.com> <56436DCE.2080204@redhat.com> Message-ID: <20151112011228.GP5336@dhcp-40-8.bne.redhat.com> On Wed, Nov 11, 2015 at 02:50:20PM -0800, Prasun Gera wrote: > I'll try this on an aws instance and report. Some googling also suggests > that the additional step of "pk12util -i ipa.example.com.p12 -d > /etc/httpd/alias" is needed, which is similar to what you suggested. A few > more questions: > 1) How would renewals work ? the pem files can be renewed on expiration > from LE's client. Would I need to run the exact same steps every time ? > Ideally, Certmonger will learn how to renew the certs with Let's Encrypt CA, by satisfying "Proof of Possession" challenges. > 2) Do expired ones need to be removed from the db in some way before > renewed ones can be added ? > IIRC you can just add the new cert. > 3) If httpd's certs expire, it won't affect any other functionality apart > from the webui right ? Are there any other side effects ? I won't be using > this for ldap certs. > RPC API is also served over HTTP; the `ipa' CLI program uses this API so it will be affected. > 4) How would I revert to IPA signed certs with automatic renewal if I want > to ? i.e. Reverting to stock configuration > Issue and track certs with Certmonger, and update HTTP configuration to use the new cert. If you want to try this please write it up and contribute to wiki! Thanks, Fraser > > On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden wrote: > > > Fraser Tweedale wrote: > > > >> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote: > >> > >>> You are right in that the fullchain.pem doesn't have the root > >>> certificate. > >>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it > >>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and > >>> Subject: > >>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root > >>> certificate for DST Root CA X3 from > >>> https://www.identrust.com/certificates/trustid/root-download-x3.html, > >>> which > >>> is self signed from what I can tell. The issuer and the subject are the > >>> same. I added that to the fullchain, and the command seemed to work. > >>> However, it messed something up, and httpd didn't start after that. httpd > >>> error log had "Unable to verify certificate 'Signing-Cert'. Add > >>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the > >>> problem can be resolved ". I added that to nss.conf, and ipactl started > >>> successfully after that. However, the webui hadn't configured the > >>> certificates properly. At this point, I just restored my backups > >>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to > >>> where things were earlier. I think it would be better to do these > >>> experiments on a test bed first. > >>> > >>> I am at a loss, and must have missed something. The purpose of this > >> command is to be able to install 3rd party certificates, yet the > >> code is expecting the certs to be signed by the IPA CA? > >> > >> Can someone explain what is going on here? > >> > > > > That isn't the problem. It doesn't require the IPA CA at all. It just > > checks that the root CA which issued the server cert is available (looks > > for subject == issuer). It would appear that something wasn't imported into > > the Apache NSS db. > > > > You'd need to re-run the import and then look at the Apache NSS database > > to ensure that the entire cert chain was imported with the proper trust > > which apparently it wasn't. > > > > # certutil -L -d /etc/httpd/alias > > > > The entire chain should be there, probably with trust like CT,, or C,,. > > > > To fix trust: > > > > # certutil -M -n "" -t CT,, -d /etc/httpd/alias > > > > To add missing certs: > > > > # certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i > > /path/to/pem > > > > Validate the web server cert. Use whatever nickname is appropriate for you: > > > > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias > > > > The more details you have on what you did to fix this the better as that > > can be used to generate a new bug to fix this upstream. > > > > rob > > From ftweedal at redhat.com Thu Nov 12 01:19:00 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 12 Nov 2015 11:19:00 +1000 Subject: [Freeipa-users] SSO Git http smart server and freeipa group authentication In-Reply-To: References: <563FD2D7.8040102@redhat.com> Message-ID: <20151112011900.GQ5336@dhcp-40-8.bne.redhat.com> On Wed, Nov 11, 2015 at 10:26:11PM +0100, John Obaterspok wrote: > Thanks Simo & Fraser, > > Creating a .netrc file on the client computer with according to the SO > postings with below content made things work perfectly! > machine gitserver.my.lan username '' password '' > machine gitserver username '' password '' > > I would like to use TLS and I've made it work by turning off ssl validation > in git: > git config --global http.sslVerify false > > If I would like to use ssl validation, is there some way to use a > certificate for the CNAME? Seems I can only add certificate (at least from > the UI) for a valid principal? > > (I'm using freeipa-server 4.2.3 on F23) > > Regards, > > -- john > Hi John, glad to hear of your success. For a certificate, you can add the (bogus) host and the principal and then issue a certificate in the normal way. $ ipa host-add gitserver.my.lan $ ipa service-add HTTP/gitserver.my.lan I'm not sure if there's a way to add the principal directly, absent a corresponding host. If someone knows how please speak up! Cheers, Fraser > > 2015-11-08 23:55 GMT+01:00 Simo Sorce : > > > On 08/11/15 08:07, John Obaterspok wrote: > > > >> Hello, > >> > >> Anyone got git-http-backend working with freeipa group auhentication and > >> would like to share their apache .conf file? > >> > >> > >> I've tried this on the IPA server with a dummy git repository setup in > >> /opt/gitrepos/test1.git > >> gitserver.my.lan is a CNAME for ipaserver.my.lan > >> > >> First, "git clone http://gitserver.my.lan/test1.git" prompts (even > >> though I > >> have a ticket) for user+pwd but still fails. > >> > >> Any suggestions are welcome! > >> > >> -- john > >> > >> > >> > >> > >> DocumentRoot /opt/gitrepos > >> > >> # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?' > >> # restorecon -R -v /opt/gitrepos > >> > >> SetEnv GIT_PROJECT_ROOT /opt/gitrepos > >> SetEnv GIT_HTTP_EXPORT_ALL > >> SetEnv REMOTE_USER $REDIRECT_REMOTE_USER > >> ScriptAlias / /usr/libexec/git-core/git-http-backend/ > >> ServerName gitserver.my.lan > >> > >> > >> Options Indexes > >> AllowOverride None > >> Require all granted > >> > >> > >> > >> Options Indexes > >> AllowOverride None > >> Require all granted > >> > >> > >> > >> AuthType Kerberos > >> AuthName "Kerberos Login" > >> KrbAuthRealm MY.LAN > >> Krb5KeyTab /etc/httpd/conf/ipa.keytab > >> KrbMethodNegotiate on > >> KrbMethodK5Passwd off > >> KrbSaveCredentials on > >> KrbVerifyKDC on > >> KrbServiceName HTTP > >> > >> AuthLDAPUrl > >> ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName > >> Require ldap-group cn=ipausers,dc=my,dc=lan > >> > > > > This should probably be somehting like: > > cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan > > > > Although you should probably create a git specific group, especially if > > you want it to be a posix group that can own files (ipausers is not a posix > > group and we are actually trying to phase it out) > > > > Also you are not doing LDAP authentication, you only want to do > > authorization, and for that you may want to actually use nsswitch based > > authorization which can be cached by sssd and not a query out to LDAP for > > each connection. > > Unfortunately the basic Apache modules do not support system group > > authentication directly, so what you may do instead is to have a cron job > > that do the following: > > getent group git-users | cut -d: -f1,4 |tr ',' ' ' > /my/authorization/file > > > > And in apache have set the following directives instead of the above two: > > AuthGroupFile /my/authorization/file > > Require group git-users > > > > HTH, > > Simo > > > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > -- > > 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 From tbordaz at redhat.com Thu Nov 12 08:38:30 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 12 Nov 2015 09:38:30 +0100 Subject: [Freeipa-users] 3/4 replica failure - unknown reasons why In-Reply-To: <9789D1C1-572F-4CB7-AE8D-26E07E94B1CB@breakthroughfuel.com> References: <9789D1C1-572F-4CB7-AE8D-26E07E94B1CB@breakthroughfuel.com> Message-ID: <56445006.50809@redhat.com> On 11/11/2015 04:20 PM, Andrew Krause wrote: > Yesterday I came in to 3 of my 4 freeipa replicas in an unusable state and replication was not connecting any of the hosts to each other. My first/primary host was still servicing authentication requests, but the others were in varying states of usability. I've investigated logs on all 4 nodes and the only thing I can see is messages like this from when the problem started until I restarted all 4 with ipactl stop/ipactl start: > > [09/Nov/2015:19:17:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:19:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:21:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:23:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:25:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:27:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:29:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:31:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:32:37 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Warning: Attempting to release replica, but unable to receive endReplication extended operation response from the replica. Error -5 (Timed out) > [09/Nov/2015:19:33:29 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:34:37 -0700] NSMMReplicationPlugin - agmt="cn=meToa.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:35:28 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > [09/Nov/2015:19:36:41 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. > > > We've already looked into our network and there was no outage/interruption between sites during the timeframe in question. The only corrective action that was taken was to restart each node. Does anyone know any way I can investigate further what caused this issue? I don't like giving "I don't know" answers for why replication stopped working and did not resume by itself. > Hi Andrew, There are quite periodic (each min or couple of min) networking issues where the primary host fails to process the replication protocol with bcloc[12]papp08. There may be problem with the 3rd replica but it is present in this portion of logs. Most of the time it prevents primary master to establish a replication session so these replica are likely late. The replicas are reachable but do not answer fast enough and the protocol times out. Default replication timeout is 10m but can be tuned in each replica agreement nsds5ReplicaTimeout. Is the value set ? As it was working fine before, it would be interesting to check the replica logs (may be enable replication logging for them) when the timeout occurs. Also, if the problem continue take periodic (under the nsds5ReplicaTimeout value) pstacks of the replica because there may be something that make them busy and unable to answer fast enough. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Nov 12 08:45:46 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Nov 2015 10:45:46 +0200 Subject: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1 In-Reply-To: References: Message-ID: <20151112084546.GH1147@redhat.com> On Wed, 11 Nov 2015, Christopher Young wrote: >Do we know what the status of getting these packages prepped and into the >mainstream repos (like EPEL, I suppose)? > >I'm just curious as I try and keep my repos minimal on servers (for obvious >reasons), but I would really like to begin testing/using the functionality >in 4.2. I believe EPEL's policy prevents you from packaging software which exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is already published as part of RHEL 7.2 beta in September. I want to remind that during this summer I ran few queries here (freeipa-users@) and elsewhere to solicit opinions whether people want to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2 release. Very few responses came back and there wasn't any convincing feedback that would have justified additional effort to make the repository and maintenance reasonable. https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html -- / Alexander Bokovoy From pbrezina at redhat.com Thu Nov 12 09:34:10 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Thu, 12 Nov 2015 10:34:10 +0100 Subject: [Freeipa-users] Sudo Rules Help In-Reply-To: <56434F97.40405@liquidweb.com> References: <56434F97.40405@liquidweb.com> Message-ID: <56445D12.6010203@redhat.com> On 11/11/2015 03:24 PM, Branden Coates wrote: > I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) that I > would greatly appreciate some help with. The core of the issue is that > sudo rules fail to work when using ldap instead of ipa when you assign > user groups and host groups to the sudo rule in place of explicitly > adding users and hosts to the sudo rule. The reason for needing to use > ldap over ipa is due to the organization requiring 2fa for all users via > OTP tokens. We have a mix of cent 5 to 7 systems, not all can be > immediately upgraded, so with cent 5 and 6 nodes ldap must be used > instead of ipa to support 2fa. > Explicitly assigning users and hosts to sudo rules is also unmanageable, > the organization has hundreds of employees and multiple thousands of > servers. Utilizing the host and user groups is a must. > > On cent 7 the default sssd.conf generated by FreeIPA works, 2fa works by > default and the sssd.conf is using the ipa directives as well to parse > user and host groups on sudo rules. Everything here works as expected. > > In cent 6 to allow 2fa to work the conf has to be updated to use ldap > instead of ipa. In the process this seems to break the ability to search > user and host groups on sudo rules. Users and hosts explicitly defined > for the sudo rules still work so the clients can see the rules, they > just do not seem to want to look within the groups that may be assigned > to the rules. I moved the original sssd.conf created by FreeIPA using > the ipa directives and sudo works as expected, but 2fa is not possible > like this. > > Cent 5 is entirely incapable of using the sudo rules with user and host > groups since sudo lacks sssd support in cent 5 and depends on > /etc/ldap.conf to work. However like cent 6, users and hosts explicitly > defined for the sudo rules still work, so I presume fixing the sudo > rules with cent 6 on ldap would fix them here as well. > > Can anyone else confirm this behavior, and if so can anyone suggest any > possible fixes or workarounds? I have attached the modified Cent6 and > Cent 5 configs for sssd and ldap inline below(first time mailing, if > inline is not ok please let me know what is preferable for future Hi, welcome to the list! I personally prefer receiving it as an attachment, since it is more convenient for me to organize and read. > reference). Currently testing using the following versions: > CentOS Linux release 7.1.1503 (Core) > CentOS release 6.7 (Final) > CentOS release 5.11 (Final) > > Cent 6 /etc/sssd/sssd.conf: > > #SSSD client configuration file. > [domain/domain] > id_provider = ldap > auth_provider = ldap > chpass_provider = ldap > autofs_provider = ldap > sudo_provider = ldap > binddn = > bindpw = > scope = sub > sudoers_base = ou=SUDOers,dc=,dc=com > tls_cacertfile = /etc/ipa/ca.crt > tls_checkpeer = yes > tls_reqcert = demand > ssl = start_tls ^ these are not sssd options thus it should not be in sssd.conf > > ldap_schema = rfc2307bis > ldap_uri = _srv_,ldap://.:389 > ldap_search_base = dc=,dc=com > ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com > ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com > ldap_sudo_search_base = ou=SUDOers,dc=,dc=com > > enumerate = True > cache_credentials = True > > ldap_tls_cacertdir = /etc/ipa/ > ldap_tls_cacert = /etc/ipa/ca.crt > ldap_tls_reqcert = demand > ldap_id_use_start_tls = True > > krb5_realm = I do not see anything wrong here at first sight. Can you send also sssd_sudo.log and sssd_$domain.log please? > > [sssd] > services = nss, sudo, pam, ssh, autofs > config_file_version = 2 > domains = domain > > [nss] > homedir_substring = /home > filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > Cent 5 /etc/sssd/sssd.conf: > > #SSSD client configuration file. > [domain/domain] > id_provider = ldap > auth_provider = ldap > chpass_provider = ldap > autofs_provider = ldap > > ldap_schema = rfc2307bis > ldap_uri = _srv_,ldap://.:389 > ldap_search_base = dc=,dc=com > ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com > ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com > > enumerate = True > cache_credentials = True > > ldap_tls_cacertdir = /etc/ipa/ > ldap_tls_cacert = /etc/ipa/ca.crt > ldap_tls_reqcert = demand > ldap_id_use_start_tls = True > > krb5_realm = > > [sssd] > services = nss, pam > config_file_version = 2 > domains = domain > > [nss] > homedir_substring = /home > filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd > > [pam] > > > Cent 5 /etc/ldap.conf: > > #LDAP client configuration file. > uri ldap://.:389 > base dc=,dc=com > ldap_version 3 > > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > ssl start_tls > > binddn > bindpw > timelimit 5 > bind_timelimit 15 > > sudoers_base ou=SUDOers,dc=,dc=com > > > Thank you > Brande > > From pvoborni at redhat.com Thu Nov 12 12:29:43 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Nov 2015 13:29:43 +0100 Subject: [Freeipa-users] REST/JSON API: Howto add a user that is not expired In-Reply-To: <20151111151314.GF1147@redhat.com> References: <564350B2.4090206@doerr-privat.de> <56435756.1030404@doerr-privat.de> <20151111151314.GF1147@redhat.com> Message-ID: <56448637.1070108@redhat.com> On 11/11/2015 04:13 PM, Alexander Bokovoy wrote: > On Wed, 11 Nov 2015, Oliver D?rr wrote: >> Hi, >> >> i've tried user_mod instead because of >> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html >> and got >> >> Error-code: 2100 >> Error-name: ACIError >> Error-msg: Insufficient access: Insufficient 'write' privilege to >> the 'krbPasswordExpiration' attribute of entry >> 'uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de'. >> >> Inside the acces log of the LDAP Server I could see... >> >> [09/Nov/2015:18:40:31 +0100] conn=658 op=7 MOD >> dn="uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de" >> [09/Nov/2015:18:40:31 +0100] conn=658 op=7 RESULT err=50 tag=103 >> nentries=0 etime=0 >> >> So it looks like it is a permission issue. But I still have the >> problem when use admin to do the job. Any idea about how to change the >> permission or an API that it is able to do the job? > You simply cannot make it working for cases when a password change > coming from a non-user. This is intentional. > > See http://www.freeipa.org/page/New_Passwords_Expired > > You can do double change via LDAP password change (or Kerberos) where > you changre a > password first to something temporary, then try to change it again as a > user with that temporary password and set a new one. Since the second > change would be done as a user, that should allow the change to happen > without raising a flag. You can use ipa/session/change_password call for that. With Content-Type:application/x-www-form-urlencoded and e.g.: user:bbar old_password:a new_password:b Web UI uses it when user with expired password is resetting his pw. So you can check the communication in browser network tab. >> >> Thanks in advance >> Oliver >> >> Am 11.11.2015 um 15:29 schrieb Oliver D?rr: >>> Hi, >>> >>> i'm still working with the JSON API and I now have the problem, that >>> I want to add a user with a not expired password. I've tried setattr >>> and addattr with the following JSON code, but both fail. >>> {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","addattr":"krbpasswordexpiration=20160207010919Z","cn":"Oliver >>> Support","sn":"Support"}],"id":0,"method":"user_add"} >>> >>> >>> {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","cn":"Oliver >>> Support","setattr":"krbpasswordexpiration=20160207010919Z","sn":"Support"}],"id":0,"method":"user_add"} >>> >>> >>> >>> >>> The user is added to IPA, but the user is still forced to change it's >>> password. In the response I could see that my krbpasswordexpiration >>> is ignored. >>> >>> Any ideas what I'm doing wrong? >>> >>> Thanks >>> Oliver >>> >> >> -- >> 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 > -- Petr Vobornik From rmj at ast.cam.ac.uk Thu Nov 12 12:35:12 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 12 Nov 2015 12:35:12 +0000 Subject: [Freeipa-users] Suggestions requested for disabling an account by date Message-ID: <56448780.1080004@ast.cam.ac.uk> Hi I'd like to find a way to disable an account on a date that we can set in the account information. ie like the Account Availability option in Solaris Management Console or the /etc/shadow "account expiration date" concept on Linux. I couldn't obviously see in the docs or on the list how to do this in freeipa. Does anyone have any suggestions? Thanks Roderick Johnstone From james.masson at jmips.co.uk Thu Nov 12 13:01:28 2015 From: james.masson at jmips.co.uk (James Masson) Date: Thu, 12 Nov 2015 13:01:28 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5633760A.7050000@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> Message-ID: <56448DA8.4000301@jmips.co.uk> On 30/10/15 13:52, Rob Crittenden wrote: > James Masson wrote: >> >> >> On 26/10/15 16:11, Martin Kosek wrote: >>> On 10/26/2015 04:05 PM, James Masson wrote: >>>> >>>> >>>> On 19/10/15 21:06, Rob Crittenden wrote: >>>>> James Masson wrote: >>>>>> >>>>>> Hi list, >>>>>> >>>>>> I successfully have IPA working with CA certs signed by an upstream >>>>>> Dogtag. >>>>>> >>>>>> Now I'm trying to use a CA cert signed by a different type of CA - >>>>>> Vault. >>>>>> >>>>>> Setup fails, using the same 2 step IPA setup process as used with >>>>>> upstream Dogtag. I've also tried the external-ca-type option. >>>>>> >>>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>>> pinpoint why. >>>>> >>>>> I'm guessing you don't include the entire CA certchain of Vault. Dogtag >>>>> is failing to startup because it can't verify its own cert chain: >>>>> >>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>> CAPresence: CA is present >>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>> SystemCertsVerification: system certs verification failure >>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>>> selftests.container.instance.SystemCertsVerification running at startup >>>>> FAILED! >>>>> >>>>> rob >>>>> >>>> >>>> >>>> Hi Rob, >>>> >>>> Thanks for the reply. >>>> >>>> I do present the IPA installer with both the CA and the IPA cert - >>>> the IPAs >>>> python-based install code is happy with the cert chain, but the Java >>>> based >>>> dogtag code chokes on it. >>>> >>>> OpenSSL is happy with it too. >>>> >>>> ##### >>>> [root at foo ~]# openssl verify ipa.crt >>>> ipa.crt: O = LOCAL, CN = Certificate Authority >>>> error 20 at 0 depth lookup:unable to get local issuer certificate >>>> >>>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>>> ipa.crt: OK >>>> ### >>>> >>>> Any hints on how to reproduce this with more debug output? I'd like >>>> to know >>>> exactly what Dogtag doesn't like about the certificate. >>>> >>>> thanks >>>> >>>> James M >>> >>> Let me CC at least Jan Ch. and David, they may be able to help and >>> should also >>> make sure FreeIPA gets better in validating the certs, as appropriate. >>> >> >> Any thoughts guys? > > I cc'd one of the dogtag guys to see if he knows. > > You might also try using certutil to validate the certificates, it might > give you some hints to what is going on. > > I'm assuming your certdb (it can vary by version) is in > /var/lib/pki/pki-tomcat/alias > > certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list of > certificates installed. You can verify each one to see what is going on. > The -u flag specfies usage. See the certutil man page for a full set of > options. > > For example: > > # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert > cert-pki-ca' > certutil: certificate is valid > > rob > Hi All, I've created a ticket to track this https://fedorahosted.org/pki/ticket/1697 Rob - certutil output: Some certificates types seem not to be approved. Not sure if this is a red herring. ############## [root at foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-ca CTu,Cu,Cu root.com CT,c, ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'root.com' certutil: certificate is invalid: Certificate type not approved for application. [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'ocspSigningCert cert-pki-ca' certutil: certificate is invalid: Certificate type not approved for application. [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' certutil: certificate is invalid: Certificate type not approved for application. [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca' certutil: certificate is valid ############# regards James M From mmalek at iisg.agh.edu.pl Thu Nov 12 13:01:36 2015 From: mmalek at iisg.agh.edu.pl (=?UTF-8?Q?Mateusz_Ma=c5=82ek?=) Date: Thu, 12 Nov 2015 14:01:36 +0100 Subject: [Freeipa-users] Suggestions requested for disabling an account by date In-Reply-To: <56448780.1080004@ast.cam.ac.uk> References: <56448780.1080004@ast.cam.ac.uk> Message-ID: <56448DB0.7040002@iisg.agh.edu.pl> Hi, W dniu 12.11.2015 o 13:35, Roderick Johnstone pisze: > I'd like to find a way to disable an account on a date that we can set > in the account information. ie like the Account Availability option in > Solaris Management Console or the /etc/shadow "account expiration > date" concept on Linux. > > I couldn't obviously see in the docs or on the list how to do this in > freeipa. > > Does anyone have any suggestions? There is " Kerberos principal expiration" field in Web UI (or --principal-expiration option in CLI). When date specified there has passed, it's no longer possible to authenticate using such account. Best regards, Mateusz Ma?ek -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmj at ast.cam.ac.uk Thu Nov 12 13:16:27 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 12 Nov 2015 13:16:27 +0000 Subject: [Freeipa-users] Suggestions requested for disabling an account by date In-Reply-To: <56448DB0.7040002@iisg.agh.edu.pl> References: <56448780.1080004@ast.cam.ac.uk> <56448DB0.7040002@iisg.agh.edu.pl> Message-ID: <5644912B.1010305@ast.cam.ac.uk> On 12/11/15 13:01, Mateusz Ma?ek wrote: > Hi, > > W dniu 12.11.2015 o 13:35, Roderick Johnstone pisze: >> I'd like to find a way to disable an account on a date that we can set >> in the account information. ie like the Account Availability option in >> Solaris Management Console or the /etc/shadow "account expiration >> date" concept on Linux. >> >> I couldn't obviously see in the docs or on the list how to do this in >> freeipa. >> >> Does anyone have any suggestions? > > There is " Kerberos principal expiration" field in Web UI (or > --principal-expiration option in CLI). When date specified there has > passed, it's no longer possible to authenticate using such account. > > Best regards, > Mateusz Ma?ek Mateusz Thanks very much for the pointer. I'm not sure how I missed that in reading the docs. Roderick From Terry.John at completeautomotivesolutions.co.uk Thu Nov 12 13:17:13 2015 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Thu, 12 Nov 2015 13:17:13 +0000 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) Message-ID: I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. My current version of ipa-server is 3.0.0-47 Certmonger crashes with a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. If I stop ipa the start certmonger it starts ok and continues to run when I start ipa again but as soon as any requests are made like "getcert list" then it crashes again. With certmonger still running I can do a request # ipa cert-status Request id: 20140417164153 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Unavailable) # service certmonger status certmonger (pid 3030) is running... This fault with the "Service Unavailable" originally came up when I tried to delete a host from the freeip gui In the file /var/log/dirsrv/slapd-PKI-IPA/errors file there was a Warning about nsslapd-cachememsize not being big enough but I don't know how to change it if, indeed this is anything to do with it. Any pointers of where to look next would be much appreciated. The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Nov 12 13:45:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Nov 2015 14:45:18 +0100 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) In-Reply-To: References: Message-ID: <564497EE.9060702@redhat.com> On 11/12/2015 02:17 PM, Terry John wrote: > I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. > > My current version of ipa-server is 3.0.0-47 > > Certmonger crashes with a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. It of course should not crash, it would be useful to have a backtrace from the core file that was generated. > If I stop ipa the start certmonger it starts ok and continues to run when I start ipa again but as soon as any requests are made like "getcert list" then it crashes again. > > With certmonger still running I can do a request > > # ipa cert-status > Request id: 20140417164153 > ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Unavailable) > # service certmonger status > certmonger (pid 3030) is running... It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. Some pointers to logs are for example here: http://www.freeipa.org/page/Troubleshooting#Server_Installation > > This fault with the "Service Unavailable" originally came up when I tried to delete a host from the freeip gui > > In the file /var/log/dirsrv/slapd-PKI-IPA/errors file there was a Warning about nsslapd-cachememsize not being big enough but I don't know how to change it if, indeed this is anything to do with it. This should not cause this error, it is more about performance tuning, AFAIK. > > Any pointers of where to look next would be much appreciated. > > > > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > V:0CF72C13B2AC > > > > > From ssorce at redhat.com Thu Nov 12 14:58:51 2015 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Nov 2015 09:58:51 -0500 Subject: [Freeipa-users] ipa-getkeytab missing permissions after migration In-Reply-To: <5643A37A.7070203@redhat.com> References: <5641F851.1070908@mittwald.de> <5643A37A.7070203@redhat.com> Message-ID: <5644A92B.5040808@redhat.com> On 11/11/15 15:22, Martin Kosek wrote: > On 11/10/2015 02:59 PM, Dominik Korittki wrote: >> >> Hello folks, >> >> I created a replica IPA host with version 4.1.0-18.el7.centos.4, >> while the initial master is a FreeIPA 3.3.3. >> >> Everything seems to work fine with the new host except for one thing: >> We have a special IPA user, which has the rights for managing and >> enrolling hosts. >> I am able to add hosts with this user, but ipa-getkeytab command >> returns the >> following message: >> >> root at ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p >> "host/testhost.internal" >> -k testhost.internal.keytab >> Failed to parse result: Insufficient access rights >> >> The keytab was successfully created, though. dirsrv error logs showed >> me this >> after raising log level: >> >> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=590 op=3 >> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" >> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny >> write on >> entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys) >> >> to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the >> subject by aci(53): aciname= "Entities are allowed to rekey managed >> entries", >> acidn="cn=accounts,dc=internal" >> [10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file >> ipa_pwd_extop.c, >> line 756]: slapi_access_allowed does not allow WRITE to >> ipaProtectedOperation;write_keys! >> [10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, >> line >> 1630]: Not allowed to set keytab on [host/testhost.internal at INTERNAL]! >> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3 >> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" >> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow >> write on >> entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) >> >> to uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by >> aci(277): >> aciname= "permission:System: Manage Host Keytab", >> acidn="cn=computers,cn=accounts,dc=internal" >> >> >> So it seems he can't find a proper write permission for >> ipaProtectedOperation;write_keys. >> When creating a permission with write access to this attribute >> everything works >> fine, but should'nt there >> already be a proper permission? I discovered the following permission: >> >> root at ipa01:~ > ipa permission-show --all --raw 'System: Manage Host >> Keytab >> Permissions' >> dn: cn=System: Manage Host Keytab >> Permissions,cn=permissions,cn=pbac,dc=internal >> cn: System: Manage Host Keytab Permissions >> ipapermright: write >> ipapermright: read >> ipapermright: compare >> ipapermright: search >> ipapermincludedattr: createtimestamp >> ipapermincludedattr: modifytimestamp >> ipapermincludedattr: entryusn >> ipapermdefaultattr: objectclass >> ipapermdefaultattr: ipaallowedtoperform;write_keys >> ipapermdefaultattr: ipaallowedtoperform;read_keys >> ipapermbindruletype: permission >> ipapermlocation: cn=computers,cn=accounts,dc=internal >> ipapermtargetfilter: (objectclass=ipahost) >> member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal >> aci: (targetattr = "createtimestamp || entryusn || >> ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || >> modifytimestamp || objectclass")(targetfilter = >> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage >> Host Keytab >> Permissions";allow (compare,read,search,write) groupdn = >> "ldap:///cn=System: >> Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=internal";) >> ipapermissiontype: V2 >> ipapermissiontype: MANAGED >> ipapermissiontype: SYSTEM >> memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal >> memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal >> memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal >> objectclass: ipapermission >> objectclass: top >> objectclass: groupofnames >> objectclass: ipapermissionv2 >> >> >> So there is a aci with write access on ipaallowedtoperform;write_keys, >> but not on ipaProtectedOperation;write_keys. >> >> So the question is: Has something gone wrong while migrating the aci's to >> freeipa v4 style? >> If yes, how can I fix it? > > > JFTR, the design for this new attribute is here: > http://www.freeipa.org/page/V4/Keytab_Retrieval > > Looking at the ACIs for ipaProtectedOperation, I see following: > > dn: cn=accounts,$SUFFIX > add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl > "Users allowed to retrieve keytab keys"; allow(read) > userattr="ipaAllowedToPerform;read_keys#USERDN";) > add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl > "Groups allowed to retrieve keytab keys"; allow(read) > userattr="ipaAllowedToPerform;read_keys#GROUPDN";) > add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Users allowed to create keytab keys"; allow(write) > userattr="ipaAllowedToPerform;write_keys#USERDN";) > add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Groups allowed to create keytab keys"; allow(write) > userattr="ipaAllowedToPerform;write_keys#GROUPDN";) > add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Entities are allowed to rekey themselves"; allow(write) > userdn="ldap:///self";) > add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Admins are allowed to rekey any entity"; allow(write) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > add:aci: > (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version > 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) > userattr="managedby#USERDN";) > > That means that hosts and services can write their own keys, or > principals in ipaAllowedToPerform;operation can do the operation, or > hosts/services in managedBy attribute can do write. > > For general keytab write access, we have the old style permission/ACI > "System: Manage Host Keytab". I tested it and it works: > > # ipa permission-show "System: Manage Host Keytab" > Permission name: System: Manage Host Keytab > Granted rights: write > Effective attributes: krblastpwdchange, krbprincipalkey > Default attributes: krbprincipalkey, krblastpwdchange > Bind rule type: permission > Subtree: cn=computers,cn=accounts,dc=rhel72 > Type: host > Granted to Privilege: Host Enrollment, Host Administrators, fbar > Indirect Member of roles: fbar, IT Specialist > > # ipa user-show fbar --all --raw > dn: uid=fbar,cn=users,cn=accounts,dc=rhel72 > ... > memberof: cn=fbar,cn=roles,cn=accounts,dc=rhel72 > memberof: cn=ipausers,cn=groups,cn=accounts,dc=rhel72 > memberofindirect: cn=fbar,cn=privileges,cn=pbac,dc=rhel72 > memberofindirect: cn=System: Manage Host > Keytab,cn=permissions,cn=pbac,dc=rhel72 > ... > # kinit fbar > # ipa-getkeytab -s `hostname` -k /tmp/fbar.keytab -p host/fbar.example.com > Failed to parse result: Insufficient access rights > > Retrying with pre-4.0 keytab retrieval method... > Keytab successfully retrieved and stored in: /tmp/fbar.keytab > > The keytab was created, but I wonder if this is expected and the > I wonder if this is expected and "System: Manage Host Keytab: should not > rather operate with ipaProtectedOperation. CCing Simo. It is not really expected, the fallback was made to allow a client to work against an older server not to work "around" permission issues. The idea is to actually change the default permissions soon(*) so that the *old* interface stops working by default and the admin has to enable it intentionally in cn=etc config option if they still have older clients around that need it. Simo. (*) I think we had a ticket, I would like it scheduled for 4.4 (I can implement it) -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Nov 12 15:21:02 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Nov 2015 10:21:02 -0500 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <56448DA8.4000301@jmips.co.uk> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> Message-ID: <5644AE5E.2020106@redhat.com> James Masson wrote: > > > On 30/10/15 13:52, Rob Crittenden wrote: >> James Masson wrote: >>> >>> >>> On 26/10/15 16:11, Martin Kosek wrote: >>>> On 10/26/2015 04:05 PM, James Masson wrote: >>>>> >>>>> >>>>> On 19/10/15 21:06, Rob Crittenden wrote: >>>>>> James Masson wrote: >>>>>>> >>>>>>> Hi list, >>>>>>> >>>>>>> I successfully have IPA working with CA certs signed by an upstream >>>>>>> Dogtag. >>>>>>> >>>>>>> Now I'm trying to use a CA cert signed by a different type of CA - >>>>>>> Vault. >>>>>>> >>>>>>> Setup fails, using the same 2 step IPA setup process as used with >>>>>>> upstream Dogtag. I've also tried the external-ca-type option. >>>>>>> >>>>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>>>> pinpoint why. >>>>>> >>>>>> I'm guessing you don't include the entire CA certchain of Vault. >>>>>> Dogtag >>>>>> is failing to startup because it can't verify its own cert chain: >>>>>> >>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>> CAPresence: CA is present >>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>> SystemCertsVerification: system certs verification failure >>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>>>> selftests.container.instance.SystemCertsVerification running at >>>>>> startup >>>>>> FAILED! >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> >>>>> Hi Rob, >>>>> >>>>> Thanks for the reply. >>>>> >>>>> I do present the IPA installer with both the CA and the IPA cert - >>>>> the IPAs >>>>> python-based install code is happy with the cert chain, but the Java >>>>> based >>>>> dogtag code chokes on it. >>>>> >>>>> OpenSSL is happy with it too. >>>>> >>>>> ##### >>>>> [root at foo ~]# openssl verify ipa.crt >>>>> ipa.crt: O = LOCAL, CN = Certificate Authority >>>>> error 20 at 0 depth lookup:unable to get local issuer certificate >>>>> >>>>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>>>> ipa.crt: OK >>>>> ### >>>>> >>>>> Any hints on how to reproduce this with more debug output? I'd like >>>>> to know >>>>> exactly what Dogtag doesn't like about the certificate. >>>>> >>>>> thanks >>>>> >>>>> James M >>>> >>>> Let me CC at least Jan Ch. and David, they may be able to help and >>>> should also >>>> make sure FreeIPA gets better in validating the certs, as appropriate. >>>> >>> >>> Any thoughts guys? >> >> I cc'd one of the dogtag guys to see if he knows. >> >> You might also try using certutil to validate the certificates, it might >> give you some hints to what is going on. >> >> I'm assuming your certdb (it can vary by version) is in >> /var/lib/pki/pki-tomcat/alias >> >> certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list of >> certificates installed. You can verify each one to see what is going on. >> The -u flag specfies usage. See the certutil man page for a full set of >> options. >> >> For example: >> >> # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert >> cert-pki-ca' >> certutil: certificate is valid >> >> rob >> > > Hi All, > > I've created a ticket to track this > > https://fedorahosted.org/pki/ticket/1697 > > Rob - certutil output: > > Some certificates types seem not to be approved. Not sure if this is a > red herring. > > ############## > [root at foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > caSigningCert cert-pki-ca CTu,Cu,Cu > root.com CT,c, > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-ca u,u,u > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'root.com' > certutil: certificate is invalid: Certificate type not approved for > application. > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'ocspSigningCert cert-pki-ca' > certutil: certificate is invalid: Certificate type not approved for > application. > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'subsystemCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'Server-Cert cert-pki-ca' > certutil: certificate is invalid: Certificate type not approved for > application. > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'auditSigningCert cert-pki-ca' > certutil: certificate is valid > ############# That's why I pointed you to the certutil man page to find out the differnet usages to test. The C usage is SSL client usage. Depending on the cert the usage may be different. rob From james.masson at jmips.co.uk Thu Nov 12 15:50:09 2015 From: james.masson at jmips.co.uk (James Masson) Date: Thu, 12 Nov 2015 15:50:09 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5644AE5E.2020106@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> <5644AE5E.2020106@redhat.com> Message-ID: <5644B531.3040507@jmips.co.uk> On 12/11/15 15:21, Rob Crittenden wrote: > James Masson wrote: >> >> >> On 30/10/15 13:52, Rob Crittenden wrote: >>> James Masson wrote: >>>> >>>> >>>> On 26/10/15 16:11, Martin Kosek wrote: >>>>> On 10/26/2015 04:05 PM, James Masson wrote: >>>>>> >>>>>> >>>>>> On 19/10/15 21:06, Rob Crittenden wrote: >>>>>>> James Masson wrote: >>>>>>>> >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I successfully have IPA working with CA certs signed by an upstream >>>>>>>> Dogtag. >>>>>>>> >>>>>>>> Now I'm trying to use a CA cert signed by a different type of CA - >>>>>>>> Vault. >>>>>>>> >>>>>>>> Setup fails, using the same 2 step IPA setup process as used with >>>>>>>> upstream Dogtag. I've also tried the external-ca-type option. >>>>>>>> >>>>>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>>>>> pinpoint why. >>>>>>> >>>>>>> I'm guessing you don't include the entire CA certchain of Vault. >>>>>>> Dogtag >>>>>>> is failing to startup because it can't verify its own cert chain: >>>>>>> >>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>> CAPresence: CA is present >>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>> SystemCertsVerification: system certs verification failure >>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>>>>> selftests.container.instance.SystemCertsVerification running at >>>>>>> startup >>>>>>> FAILED! >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> >>>>>> Hi Rob, >>>>>> >>>>>> Thanks for the reply. >>>>>> >>>>>> I do present the IPA installer with both the CA and the IPA cert - >>>>>> the IPAs >>>>>> python-based install code is happy with the cert chain, but the Java >>>>>> based >>>>>> dogtag code chokes on it. >>>>>> >>>>>> OpenSSL is happy with it too. >>>>>> >>>>>> ##### >>>>>> [root at foo ~]# openssl verify ipa.crt >>>>>> ipa.crt: O = LOCAL, CN = Certificate Authority >>>>>> error 20 at 0 depth lookup:unable to get local issuer certificate >>>>>> >>>>>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>>>>> ipa.crt: OK >>>>>> ### >>>>>> >>>>>> Any hints on how to reproduce this with more debug output? I'd like >>>>>> to know >>>>>> exactly what Dogtag doesn't like about the certificate. >>>>>> >>>>>> thanks >>>>>> >>>>>> James M >>>>> >>>>> Let me CC at least Jan Ch. and David, they may be able to help and >>>>> should also >>>>> make sure FreeIPA gets better in validating the certs, as appropriate. >>>>> >>>> >>>> Any thoughts guys? >>> >>> I cc'd one of the dogtag guys to see if he knows. >>> >>> You might also try using certutil to validate the certificates, it might >>> give you some hints to what is going on. >>> >>> I'm assuming your certdb (it can vary by version) is in >>> /var/lib/pki/pki-tomcat/alias >>> >>> certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list of >>> certificates installed. You can verify each one to see what is going on. >>> The -u flag specfies usage. See the certutil man page for a full set of >>> options. >>> >>> For example: >>> >>> # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert >>> cert-pki-ca' >>> certutil: certificate is valid >>> >>> rob >>> >> >> Hi All, >> >> I've created a ticket to track this >> >> https://fedorahosted.org/pki/ticket/1697 >> >> Rob - certutil output: >> >> Some certificates types seem not to be approved. Not sure if this is a >> red herring. >> >> ############## >> [root at foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> caSigningCert cert-pki-ca CTu,Cu,Cu >> root.com CT,c, >> ocspSigningCert cert-pki-ca u,u,u >> subsystemCert cert-pki-ca u,u,u >> Server-Cert cert-pki-ca u,u,u >> auditSigningCert cert-pki-ca u,u,Pu >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'caSigningCert cert-pki-ca' >> certutil: certificate is valid >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'root.com' >> certutil: certificate is invalid: Certificate type not approved for >> application. >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'ocspSigningCert cert-pki-ca' >> certutil: certificate is invalid: Certificate type not approved for >> application. >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> certutil: certificate is valid >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'Server-Cert cert-pki-ca' >> certutil: certificate is invalid: Certificate type not approved for >> application. >> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >> 'auditSigningCert cert-pki-ca' >> certutil: certificate is valid >> ############# > > That's why I pointed you to the certutil man page to find out the > differnet usages to test. The C usage is SSL client usage. Depending on > the cert the usage may be different. > > rob Missed that. Here are those commands again with different certusage checking In short, they're all superficially valid. ########## [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n 'root.com' certutil: certificate is valid [root at foo ~]# certutil -V -u O -d /var/lib/pki/pki-tomcat/alias -n 'ocspSigningCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u J -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca' certutil: certificate is valid #### However, the debug logs seem to indicate the 'caSigningCert cert-pki-ca' is the one it has problems with. #### [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=signing [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: verifySystemCertByTag(signing) [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(caSigningCert cert-pki-ca,SSLCA) [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca [12/Nov/2015:12:41:35][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Failure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate verification ######### But further checking seems to indicate the cert passes the relevant checks ( Y A L ) ###### [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u A -d /var/lib/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' certutil: certificate is valid [root at foo ~]# certutil -V -u L -d /var/lib/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' certutil: certificate is valid ##### regards James M From Terry.John at completeautomotivesolutions.co.uk Thu Nov 12 15:51:44 2015 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Thu, 12 Nov 2015 15:51:44 +0000 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) In-Reply-To: <564497EE.9060702@redhat.com> References: <564497EE.9060702@redhat.com> Message-ID: I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. On 11/12/2015 02:17 PM, Terry John wrote: >> I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. >> My current version of ipa-server is 3.0.0-47 >> Certmonger crashes with a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. >It of course should not crash, it would be useful to have a backtrace from the core file that was generated. Here is the backtrace of the core file: { "signal": 11 , "executable": "/usr/sbin/certmonger" , "stacktrace": [ { "crash_thread": true , "frames": [ { "address": 140527158519285 , "build_id": "87a19a61dc011579f3e25de3ca9778c6fd9e4547" , "build_id_offset": 1222133 , "function_name": "__strstr_sse42" , "file_name": "/lib64/libc.so.6" } , { "address": 140527209363149 , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" , "build_id_offset": 141005 , "file_name": "/usr/sbin/certmonger" } , { "address": 140527209301676 , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" , "build_id_offset": 79532 , "file_name": "/usr/sbin/certmonger" } , { "address": 140527209287550 , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" , "build_id_offset": 65406 , "file_name": "/usr/sbin/certmonger" } , { "address": 140527209291166 , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" , "build_id_offset": 69022 , "file_name": "/usr/sbin/certmonger" } , { "address": 140527196303038 , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" , "build_id_offset": 36542 , "file_name": "/usr/lib64/libtevent.so.0" } , { "address": 140527196295910 , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" , "build_id_offset": 29414 , "file_name": "/usr/lib64/libtevent.so.0" } , { "address": 140527196279965 , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" , "build_id_offset": 13469 , "function_name": "_tevent_loop_once" , "file_name": "/usr/lib64/libtevent.so.0" } , { "address": 140527209278079 , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" , "build_id_offset": 55935 , "function_name": "main" , "file_name": "/usr/sbin/certmonger" } ] } ] } In /var/log/messages I get freeipasvr kernel: certmonger[2611] general protection ip:7fb487fed5f5 sp:7ffd9df46898 error:0 in libc-2.12.so[7fb487ec3000+18a000] This is the first error I get in /var/log/httpd/error_log when I try to delete a host [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Service Unavailable) >> If I stop ipa the start certmonger it starts ok and continues to run when I start ipa again but as soon as any requests are made like "getcert list" then it crashes again. >> With certmonger still running I can do a request > >> # ipa cert-status > >Request id: 20140417164153 > >ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (Service Unavailable) # service certmonger status > >certmonger (pid 3030) is running... >It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. Yes ipa cert-show 1 does show the same thing # ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Unavailable) >Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. I'm sure SELinux is not an issue. There are no AVC errors in /var/log/audit/audit.log and it fails the same way in 'Enforcing' and 'Permissive' modes I'm pretty certain the dogtag service is not running >Some pointers to logs are for example here: >http://www.freeipa.org/page/Troubleshooting#Server_Installation /var/log/pki-ca/catalina.out contains the lines at boot time: INFO: Deploying web application directory ca Nov 12, 2015 3:33:47 PM org.apache.tomcat.util.modeler.Registry registerComponent SEVERE: Null component Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/ca,J2EEApplication=none,J2EEServer=none Nov 12, 2015 3:33:47 PM org.apache.catalina.startup.HostConfig deployDirectory SEVERE: Error deploying web application directory ca java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2334).... lots of traceback /var/log/pki-ca/system is empty /var/log/pki-ca/debug has nothing new for 2 days >> This fault with the "Service Unavailable" originally came up when I >> tried to delete a host from the freeip gui >> In the file /var/log/dirsrv/slapd-PKI-IPA/errors file there was a Warning about nsslapd-cachememsize not being big enough but I don't know how to change it if, indeed this is anything to do with it. >This should not cause this error, it is more about performance tuning, AFAIK. That's good to know.. The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC From rcritten at redhat.com Thu Nov 12 16:15:09 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Nov 2015 11:15:09 -0500 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5644B531.3040507@jmips.co.uk> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> <5644AE5E.2020106@redhat.com> <5644B531.3040507@jmips.co.uk> Message-ID: <5644BB0D.3030209@redhat.com> James Masson wrote: > > > On 12/11/15 15:21, Rob Crittenden wrote: >> James Masson wrote: >>> >>> >>> On 30/10/15 13:52, Rob Crittenden wrote: >>>> James Masson wrote: >>>>> >>>>> >>>>> On 26/10/15 16:11, Martin Kosek wrote: >>>>>> On 10/26/2015 04:05 PM, James Masson wrote: >>>>>>> >>>>>>> >>>>>>> On 19/10/15 21:06, Rob Crittenden wrote: >>>>>>>> James Masson wrote: >>>>>>>>> >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I successfully have IPA working with CA certs signed by an >>>>>>>>> upstream >>>>>>>>> Dogtag. >>>>>>>>> >>>>>>>>> Now I'm trying to use a CA cert signed by a different type of CA - >>>>>>>>> Vault. >>>>>>>>> >>>>>>>>> Setup fails, using the same 2 step IPA setup process as used with >>>>>>>>> upstream Dogtag. I've also tried the external-ca-type option. >>>>>>>>> >>>>>>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>>>>>> pinpoint why. >>>>>>>> >>>>>>>> I'm guessing you don't include the entire CA certchain of Vault. >>>>>>>> Dogtag >>>>>>>> is failing to startup because it can't verify its own cert chain: >>>>>>>> >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> CAPresence: CA is present >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> SystemCertsVerification: system certs verification failure >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>>>>>> selftests.container.instance.SystemCertsVerification running at >>>>>>>> startup >>>>>>>> FAILED! >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Rob, >>>>>>> >>>>>>> Thanks for the reply. >>>>>>> >>>>>>> I do present the IPA installer with both the CA and the IPA cert - >>>>>>> the IPAs >>>>>>> python-based install code is happy with the cert chain, but the Java >>>>>>> based >>>>>>> dogtag code chokes on it. >>>>>>> >>>>>>> OpenSSL is happy with it too. >>>>>>> >>>>>>> ##### >>>>>>> [root at foo ~]# openssl verify ipa.crt >>>>>>> ipa.crt: O = LOCAL, CN = Certificate Authority >>>>>>> error 20 at 0 depth lookup:unable to get local issuer certificate >>>>>>> >>>>>>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>>>>>> ipa.crt: OK >>>>>>> ### >>>>>>> >>>>>>> Any hints on how to reproduce this with more debug output? I'd like >>>>>>> to know >>>>>>> exactly what Dogtag doesn't like about the certificate. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> James M >>>>>> >>>>>> Let me CC at least Jan Ch. and David, they may be able to help and >>>>>> should also >>>>>> make sure FreeIPA gets better in validating the certs, as >>>>>> appropriate. >>>>>> >>>>> >>>>> Any thoughts guys? >>>> >>>> I cc'd one of the dogtag guys to see if he knows. >>>> >>>> You might also try using certutil to validate the certificates, it >>>> might >>>> give you some hints to what is going on. >>>> >>>> I'm assuming your certdb (it can vary by version) is in >>>> /var/lib/pki/pki-tomcat/alias >>>> >>>> certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list of >>>> certificates installed. You can verify each one to see what is going >>>> on. >>>> The -u flag specfies usage. See the certutil man page for a full set of >>>> options. >>>> >>>> For example: >>>> >>>> # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>>> 'auditSigningCert >>>> cert-pki-ca' >>>> certutil: certificate is valid >>>> >>>> rob >>>> >>> >>> Hi All, >>> >>> I've created a ticket to track this >>> >>> https://fedorahosted.org/pki/ticket/1697 >>> >>> Rob - certutil output: >>> >>> Some certificates types seem not to be approved. Not sure if this is a >>> red herring. >>> >>> ############## >>> [root at foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias >>> >>> Certificate Nickname Trust >>> Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> >>> caSigningCert cert-pki-ca CTu,Cu,Cu >>> root.com CT,c, >>> ocspSigningCert cert-pki-ca u,u,u >>> subsystemCert cert-pki-ca u,u,u >>> Server-Cert cert-pki-ca u,u,u >>> auditSigningCert cert-pki-ca u,u,Pu >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'caSigningCert cert-pki-ca' >>> certutil: certificate is valid >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'root.com' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'ocspSigningCert cert-pki-ca' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'subsystemCert cert-pki-ca' >>> certutil: certificate is valid >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'Server-Cert cert-pki-ca' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'auditSigningCert cert-pki-ca' >>> certutil: certificate is valid >>> ############# >> >> That's why I pointed you to the certutil man page to find out the >> differnet usages to test. The C usage is SSL client usage. Depending on >> the cert the usage may be different. >> >> rob > > Missed that. Here are those commands again with different certusage > checking > > In short, they're all superficially valid. > > ########## > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n > 'root.com' > certutil: certificate is valid > > > [root at foo ~]# certutil -V -u O -d /var/lib/pki/pki-tomcat/alias -n > 'ocspSigningCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n > 'subsystemCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n > 'Server-Cert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u J -d /var/lib/pki/pki-tomcat/alias -n > 'auditSigningCert cert-pki-ca' > certutil: certificate is valid > #### > > > However, the debug logs seem to indicate the 'caSigningCert cert-pki-ca' > is the one it has problems with. > > #### > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=signing > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByTag(signing) > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(caSigningCert cert-pki-ca,SSLCA) > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed: caSigningCert cert-pki-ca > [12/Nov/2015:12:41:35][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Failure][CertNickName=caSigningCert > cert-pki-ca] CIMC certificate verification > ######### > > But further checking seems to indicate the cert passes the relevant > checks ( Y A L ) > > ###### > [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u A -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u L -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > ##### > Ok, yeah, we'll need to wait for the dogtag guys to chime in here or on the ticket. Note that validity also depends on valid to/from dates so you might check that too, but it's a stretch to suggest that's the problem. rob From simo at redhat.com Thu Nov 12 18:39:26 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Nov 2015 13:39:26 -0500 Subject: [Freeipa-users] krb5kdc will not start (kerberos authentication error) In-Reply-To: <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771828B673@hqexdb01.hqfincen.gov> <5640CDB5.4000707@redhat.com> <2909CC7109523F4BA968E7A201471B771828B808@hqexdb01.hqfincen.gov> <56410155.2090009@redhat.com> <2909CC7109523F4BA968E7A201471B771828BCC4@hqexdb01.hqfincen.gov> <20151110131814.GS1147@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD04@hqexdb01.hqfincen.gov> <20151110134033.GT1147@redhat.com> <5641F914.7040600@redhat.com> <2909CC7109523F4BA968E7A201471B771828BD9F@hqexdb01.hqfincen.gov> <5642038A.5050505@redhat.com> <2909CC7109523F4BA968E7A201471B771828BDC3@hqexdb01.hqfincen.gov> <56420782.2030408@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE14@hqexdb01.hqfincen.gov> <5642157D.30900@redhat.com> <2909CC7109523F4BA968E7A201471B771828BE75@hqexdb01.hqfincen.gov> <56421AE2.4080900@redhat.com> <56421D3B.90704@redhat.com> <2909CC7109523F4BA968E7A201471B771828BEFF@hqexdb01.hqfincen.gov> <564220AF.9010701@redhat.com> <2909CC7109523F4BA968E7A201471B771828BF5C@hqexdb01.hqfincen.gov> Message-ID: <5644DCDE.8020406@redhat.com> On 10/11/15 11:54, Gronde, Christopher (Contractor) wrote: > # ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mapping, sasl, config > dn: cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsContainer > cn: mapping It seem like you have mappings that shouldn't be there in EL6. During ipa-server[replica]-install we explicitly replace all mappings with IPA ones, but it seem that something is wrong on your server and you have both the default DS mappings (which we usually remove at install time) and the IPA mappings. You should have only: cn=Full Principal,cn=mapping,cn=sasl,cn=config cn=Name Only,cn=mapping,cn=sasl,cn=config Please remove: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config cn=uid mapping,cn=mapping,cn=sasl,cn=config And your server will be able again to properly resolve sasl mappings. HTH, Simo. > # Full Principal, mapping, sasl, config > dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: \(.*\)@\(.*\) > cn: Full Principal > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) > > # Kerberos uid mapping, mapping, sasl, config > dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: Kerberos uid mapping > nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) > nsSaslMapBaseDNTemplate: dc=\2,dc=\3 > nsSaslMapFilterTemplate: (uid=\1) > > # Name Only, mapping, sasl, config > dn: cn=Name Only,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > nsSaslMapRegexString: ^[^:@]+$ > cn: Name Only > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV) > > # rfc 2829 dn syntax, mapping, sasl, config > dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 dn syntax > nsSaslMapRegexString: ^dn:\(.*\) > nsSaslMapBaseDNTemplate: \1 > nsSaslMapFilterTemplate: (objectclass=*) > > # rfc 2829 u syntax, mapping, sasl, config > dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: rfc 2829 u syntax > nsSaslMapRegexString: ^u:\(.*\) > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=\1) > > # uid mapping, mapping, sasl, config > dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config > objectClass: top > objectClass: nsSaslMapping > cn: uid mapping > nsSaslMapRegexString: ^[^:@]+$ > nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov > nsSaslMapFilterTemplate: (uid=&) > > # search result > search: 2 > result: 0 Success > > # numResponses: 8 > # numEntries: 7 > [root at comipa02 ~]# > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, November 10, 2015 11:52 AM > To: Gronde, Christopher (Contractor) ; Ludwig Krispenz ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error) > > Gronde, Christopher (Contractor) wrote: >> This gave me a huge return! Appears to be a long list of all the servers and applications whose users authenticate to the IPA servers. >> >> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b "dc=itmodev,dc=gov" '(objectclass=krbprincipal)' >> >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 142 >> # numEntries: 141 > > Right, we need to see the sasl mapping: > > $ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config > > rob > >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig Krispenz >> Sent: Tuesday, November 10, 2015 11:37 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >> authentication error) >> >> what do you get if you search for "objectclass=krbprincipal" ? >> >> On 11/10/2015 05:27 PM, Rich Megginson wrote: >>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote: >>>> Neither came back with anything >>>> >>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> Enter LDAP Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/comipa01.itmodev.gov) # requesting: ALL # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> [root at comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory >>>> manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP >>>> Password: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base with scope subtree # filter: >>>> (uid=ldap/*.gov) # requesting: uid # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>> >>> That means this server has no LDAP service principals? I'm not sure >>> how to recover IPA from this scenario. >>> >>>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich >>>> Megginson >>>> Sent: Tuesday, November 10, 2015 11:04 AM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>> authentication error) >>>> >>>> On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote: >>>>> Thank you! I should have caught that... >>>>> >>>>> I changed the log level and then restarted dirsrv and attempted to >>>>> start krb5kdc and got the following... >>>> >>>> >>>> [10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from >>>> 172.16.100.208 to 172.16.100.161 >>>> [10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 >>>> nentries=0 etime=1, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 >>>> nentries=0 etime=0, SASL bind in progress >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl >>>> version=3 mech=GSSAPI >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH >>>> base="dc=itmodev,dc=gov" scope=2 >>>> filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL >>>> [10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 >>>> nentries=0 etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 >>>> nentries=0 >>>> etime=0 >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND >>>> [10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1 >>>> >>>> >>>> >>>> This is the SASL bind. It thinks the principal in the Kerberos >>>> credential is "ldap/comipa01.itmodev.gov", and the SASL map tells >>>> the code to look for something with uid=ldap/comipa01.itmodev.gov >>>> under dc=itmodev,dc=gov. However, this entry is not found: RESULT >>>> err=0 >>>> tag=48 nentries=0. nentries=0 means no entries matched the search >>>> criteria. >>>> >>>> You can do the search yourself with ldapsearch: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)' >>>> >>>> If you want to find out if there is some other ldap principal, do a >>>> search like this: >>>> >>>> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b >>>> "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid >>>> >>>>>> Ran into an error trying to set that >>>>>> >>>>>> # ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password: >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> : 260 >>>>>> >>>>>> modifying entry "cn=config" >>>>>> ldap_modify: Server is unwilling to perform (53) >>>>>> additional info: Unknown attribute >>>>>> nsslapd-acesslog-level will be ignored >>>>>> >>>>>> [root at comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP >>>>>> Password: >>>>>> ldap_bind: Inappropriate authentication (48) >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ludwig Krispenz [mailto:lkrispen at redhat.com] >>>>>> Sent: Tuesday, November 10, 2015 9:48 AM >>>>>> To: Gronde, Christopher (Contractor) >>>>>> >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>> authentication error) >>>>>> >>>>>> >>>>>> On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote: >>>>>>> How do I change that log setting? Is that done in LDAP? Using >>>>>>> ldapmodify? >>>>>> yes, >>>>>> ldapmodify ... >>>>>> dn: cn=config >>>>>> changetype: modify >>>>>> replace: nsslapd-acesslog-level >>>>>> nsslapd-acesslog-level: 260 >>>>>>> -----Original Message----- >>>>>>> From: freeipa-users-bounces at redhat.com >>>>>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ludwig >>>>>>> Krispenz >>>>>>> Sent: Tuesday, November 10, 2015 9:03 AM >>>>>>> To: freeipa-users at redhat.com >>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>> authentication error) >>>>>>> >>>>>>> >>>>>>> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>> Where can I verify or change the credentials it is trying to use? >>>>>>>>> Is it my LDAP password? >>>>>>>> No, according to your logs, it is your LDAP master trying to >>>>>>>> replicate (push changes) to your LDAP replica: >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>> err=49 could also be a result if the entry which is mapped from >>>>>>> the principal is not found in the directory. A bit more info >>>>>>> could be gained by enabling logging of internal searches. >>>>>>> Set nsslapd-acesslog-level: 260 >>>>>>> >>>>>>> and then look what internal searches are done during the gssapi >>>>>>> authentication >>>>>>>> If that is true, it would be ldap/ Kerberos principal >>>>>>>> talking to ldap/ Kerberos principal. If that fails, it >>>>>>>> means master and replica KDCs have different understanding of >>>>>>>> both ldap/ and ldap/ keys which most likely >>>>>>>> means keys were rotated on master and weren't propagated to replica. >>>>>>>> >>>>>>>> How to solve it? One possibility is to set master's hostname as >>>>>>>> KDC address in krb5.conf on replica, forcing LDAP server on >>>>>>>> replica to use master's KDC. I'm absolutely not sure this will >>>>>>>> actually work but at least it allows to see if we are indeed >>>>>>>> dealing with inconsistent state of service principals' keys. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>> Sent: Tuesday, November 10, 2015 8:18 AM >>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>> >>>>>>>>> Cc: Rob Crittenden ; >>>>>>>>> freeipa-users at redhat.com >>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>> authentication error) >>>>>>>>> >>>>>>>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>> When I tried to start the service again I got no response from >>>>>>>>>> tail of the log, but this is a repeating entry I see in the >>>>>>>>>> access log >>>>>>>>>> >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection >>>>>>>>>> from >>>>>>>>>> 127.0.0.1 to 127.0.0.1 >>>>>>>>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection >>>>>>>>>> from to >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 >>>>>>>>>> nentries=0 etime=0, SASL bind in progress >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" >>>>>>>>>> method=sasl >>>>>>>>>> version=3 mech=GSSAPI >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 >>>>>>>>>> nentries=0 etime=0 >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND >>>>>>>>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1 >>>>>>>>>> >>>>>>>>>> Does anyone know what err=14 or err=49 are? >>>>>>>>> err=14 means SASL bind in progress -- i.e. multi-round >>>>>>>>> processing is ongoing. This is normal for SASL GSSAPI. >>>>>>>>> >>>>>>>>> err=49 is wrong password or username, i.e. credentials were >>>>>>>>> incorrect. >>>>>>>>> It may also mean that LDAP server side was unable to process >>>>>>>>> Kerberos negotiation due to not having a current Kerberos >>>>>>>>> ticket for own service >>>>>>>>> (LDAP) and trying to request it from the Kerberos KDC but >>>>>>>>> Kerberos KDC is down. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>> Sent: Monday, November 09, 2015 3:26 PM >>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>> authentication error) >>>>>>>>>> >>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>> Nothing bad came back and there is definitely data in the tree. >>>>>>>>>> Ok, I guess I'd try to start the kdc again and then watch the >>>>>>>>>> 389-ds access log (buffered) to: >>>>>>>>>> >>>>>>>>>> 1. See if it is binding at all 2. See what the search is and >>>>>>>>>> what, if any, results were returned >>>>>>>>>> >>>>>>>>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>>>>>>>>> Sent: Monday, November 09, 2015 11:46 AM >>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>> ; Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos >>>>>>>>>>> authentication error) >>>>>>>>>>> >>>>>>>>>>> Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>> I restarted dirsrv and attempted to start krb5kdc and this >>>>>>>>>>>> is what the error log shows >>>>>>>>>>>> >>>>>>>>>>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:01:02 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - >>>>>>>>>>>> signaling operation threads >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing >>>>>>>>>>>> down internal subsystems and plugins >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database >>>>>>>>>>>> threads to stop >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - All database threads now >>>>>>>>>>>> stopped >>>>>>>>>>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 >>>>>>>>>>>> B2015.247.1737 starting up >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry >>>>>>>>>>>> cache size 10485760B is less than db size 28016640B; We >>>>>>>>>>>> recommend to increase the entry cache size nsslapd-cachememsize. >>>>>>>>>>>> [09/Nov/2015:11:14:20 -0500] - slapd started. Listening on >>>>>>>>>>>> All Interfaces port 389 for LDAP requests >>>>>>>>>>> Ok, that's good. >>>>>>>>>>> >>>>>>>>>>> I'd do something like this to see what is in the db >>>>>>>>>>> (substitute example.com with your domain): >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b >>>>>>>>>>> cn=kerberos,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> (don't post the output as it would include the kerberos >>>>>>>>>>> master key). >>>>>>>>>>> >>>>>>>>>>> If that returns nothing that's bad. >>>>>>>>>>> >>>>>>>>>>> If it succeeds I'd broaden the search base a bit to see what >>>>>>>>>>> data you do >>>>>>>>>>> have: >>>>>>>>>>> >>>>>>>>>>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b >>>>>>>>>>> cn=groups,cn=accounts,dc=example,dc=com >>>>>>>>>>> >>>>>>>>>>> I picked groups because usually groups << users in numbers. >>>>>>>>>>> This is just to see if you have data in the tree. >>>>>>>>>>> >>>>>>>>>>> Let us know if either or both turns up nothing. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>>>>>>>>> Sent: Monday, November 09, 2015 10:51 AM >>>>>>>>>>>> To: Gronde, Christopher (Contractor) >>>>>>>>>>>> >>>>>>>>>>>> Cc: freeipa-users at redhat.com >>>>>>>>>>>> Subject: Re: [Freeipa-users] krb5kdc will not start >>>>>>>>>>>> (kerberos authentication error) >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote: >>>>>>>>>>>>> Hello all! >>>>>>>>>>>>> >>>>>>>>>>>>> On my replica IPA server after fixing a cert issue that had >>>>>>>>>>>>> been going on for sometime, I have all my certs figured out >>>>>>>>>>>>> but the krb5kdc service will not start. >>>>>>>>>>>>> >>>>>>>>>>>>> # service krb5kdc start >>>>>>>>>>>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm >>>>>>>>>>>>> ITMODEV.GOV - see log file for details >>>>>>>>>>>>> [FAILED] >>>>>>>>>>>>> >>>>>>>>>>>>> # cat /var/log/krb5kdc.log >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> krb5kdc: Server error - while fetching master key K/M for >>>>>>>>>>>>> realm ITMODEV.GOV >>>>>>>>>>>>> >>>>>>>>>>>>> I found this article online: >>>>>>>>>>>>> http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.sht >>>>>>>>>>>>> m >>>>>>>>>>>>> l >>>>>>>>>>>>> >>>>>>>>>>>>> Which stated it might be because The slave KDC does not >>>>>>>>>>>>> have a stash file (.k5.EXAMPLE.COM). You need to create one. >>>>>>>>>>>>> Tried the command >>>>>>>>>>>>> listed: >>>>>>>>>>>>> >>>>>>>>>>>>> # kdb5_util stash >>>>>>>>>>>>> kdb5_util: Server error while retrieving master entry >>>>>>>>>>>>> >>>>>>>>>>>>> No further information found on the proceeding error above >>>>>>>>>>>>> for the kdb5_util command. >>>>>>>>>>>>> >>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>> First: don't use instructions which are not related to IPA, >>>>>>>>>>>> please. >>>>>>>>>>>> >>>>>>>>>>>> FreeIPA has its own LDAP driver for KDC and instructions for >>>>>>>>>>>> anything else do not apply here at all. >>>>>>>>>>>> >>>>>>>>>>>> If you see 'Server error - while fetching master key ..' it >>>>>>>>>>>> means KDC LDAP driver was unable to contact LDAP server. >>>>>>>>>>>> Does LDAP server work on the replica? What is in its error >>>>>>>>>>>> log (/var/log/dirsrv/slapd-ITMODEV-GOV/errors)? >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> / 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 >> >> > > > -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Nov 12 19:35:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Nov 2015 20:35:40 +0100 Subject: [Freeipa-users] ipa-getkeytab missing permissions after migration In-Reply-To: <5644A92B.5040808@redhat.com> References: <5641F851.1070908@mittwald.de> <5643A37A.7070203@redhat.com> <5644A92B.5040808@redhat.com> Message-ID: <5644EA0C.6090708@redhat.com> On 11/12/2015 03:58 PM, Simo Sorce wrote: > On 11/11/15 15:22, Martin Kosek wrote: >> On 11/10/2015 02:59 PM, Dominik Korittki wrote: >>> >>> Hello folks, >>> >>> I created a replica IPA host with version 4.1.0-18.el7.centos.4, >>> while the initial master is a FreeIPA 3.3.3. >>> >>> Everything seems to work fine with the new host except for one thing: >>> We have a special IPA user, which has the rights for managing and >>> enrolling hosts. >>> I am able to add hosts with this user, but ipa-getkeytab command >>> returns the >>> following message: >>> >>> root at ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p >>> "host/testhost.internal" >>> -k testhost.internal.keytab >>> Failed to parse result: Insufficient access rights >>> >>> The keytab was successfully created, though. dirsrv error logs showed >>> me this >>> after raising log level: >>> >>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=590 op=3 >>> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" >>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny >>> write on >>> entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys) >>> >>> >>> to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the >>> subject by aci(53): aciname= "Entities are allowed to rekey managed >>> entries", >>> acidn="cn=accounts,dc=internal" >>> [10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file >>> ipa_pwd_extop.c, >>> line 756]: slapi_access_allowed does not allow WRITE to >>> ipaProtectedOperation;write_keys! >>> [10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, >>> line >>> 1630]: Not allowed to set keytab on [host/testhost.internal at INTERNAL]! >>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3 >>> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal" >>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow >>> write on >>> entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) >>> >>> >>> to uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by >>> aci(277): >>> aciname= "permission:System: Manage Host Keytab", >>> acidn="cn=computers,cn=accounts,dc=internal" >>> >>> >>> So it seems he can't find a proper write permission for >>> ipaProtectedOperation;write_keys. >>> When creating a permission with write access to this attribute >>> everything works >>> fine, but should'nt there >>> already be a proper permission? I discovered the following permission: >>> >>> root at ipa01:~ > ipa permission-show --all --raw 'System: Manage Host >>> Keytab >>> Permissions' >>> dn: cn=System: Manage Host Keytab >>> Permissions,cn=permissions,cn=pbac,dc=internal >>> cn: System: Manage Host Keytab Permissions >>> ipapermright: write >>> ipapermright: read >>> ipapermright: compare >>> ipapermright: search >>> ipapermincludedattr: createtimestamp >>> ipapermincludedattr: modifytimestamp >>> ipapermincludedattr: entryusn >>> ipapermdefaultattr: objectclass >>> ipapermdefaultattr: ipaallowedtoperform;write_keys >>> ipapermdefaultattr: ipaallowedtoperform;read_keys >>> ipapermbindruletype: permission >>> ipapermlocation: cn=computers,cn=accounts,dc=internal >>> ipapermtargetfilter: (objectclass=ipahost) >>> member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal >>> aci: (targetattr = "createtimestamp || entryusn || >>> ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || >>> modifytimestamp || objectclass")(targetfilter = >>> "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage >>> Host Keytab >>> Permissions";allow (compare,read,search,write) groupdn = >>> "ldap:///cn=System: >>> Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=internal";) >>> ipapermissiontype: V2 >>> ipapermissiontype: MANAGED >>> ipapermissiontype: SYSTEM >>> memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal >>> memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal >>> memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal >>> objectclass: ipapermission >>> objectclass: top >>> objectclass: groupofnames >>> objectclass: ipapermissionv2 >>> >>> >>> So there is a aci with write access on ipaallowedtoperform;write_keys, >>> but not on ipaProtectedOperation;write_keys. >>> >>> So the question is: Has something gone wrong while migrating the aci's to >>> freeipa v4 style? >>> If yes, how can I fix it? >> >> >> JFTR, the design for this new attribute is here: >> http://www.freeipa.org/page/V4/Keytab_Retrieval >> >> Looking at the ACIs for ipaProtectedOperation, I see following: >> >> dn: cn=accounts,$SUFFIX >> add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl >> "Users allowed to retrieve keytab keys"; allow(read) >> userattr="ipaAllowedToPerform;read_keys#USERDN";) >> add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl >> "Groups allowed to retrieve keytab keys"; allow(read) >> userattr="ipaAllowedToPerform;read_keys#GROUPDN";) >> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Users allowed to create keytab keys"; allow(write) >> userattr="ipaAllowedToPerform;write_keys#USERDN";) >> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Groups allowed to create keytab keys"; allow(write) >> userattr="ipaAllowedToPerform;write_keys#GROUPDN";) >> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Entities are allowed to rekey themselves"; allow(write) >> userdn="ldap:///self";) >> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Admins are allowed to rekey any entity"; allow(write) groupdn = >> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> add:aci: >> (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version >> >> 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) >> userattr="managedby#USERDN";) >> >> That means that hosts and services can write their own keys, or >> principals in ipaAllowedToPerform;operation can do the operation, or >> hosts/services in managedBy attribute can do write. >> >> For general keytab write access, we have the old style permission/ACI >> "System: Manage Host Keytab". I tested it and it works: >> >> # ipa permission-show "System: Manage Host Keytab" >> Permission name: System: Manage Host Keytab >> Granted rights: write >> Effective attributes: krblastpwdchange, krbprincipalkey >> Default attributes: krbprincipalkey, krblastpwdchange >> Bind rule type: permission >> Subtree: cn=computers,cn=accounts,dc=rhel72 >> Type: host >> Granted to Privilege: Host Enrollment, Host Administrators, fbar >> Indirect Member of roles: fbar, IT Specialist >> >> # ipa user-show fbar --all --raw >> dn: uid=fbar,cn=users,cn=accounts,dc=rhel72 >> ... >> memberof: cn=fbar,cn=roles,cn=accounts,dc=rhel72 >> memberof: cn=ipausers,cn=groups,cn=accounts,dc=rhel72 >> memberofindirect: cn=fbar,cn=privileges,cn=pbac,dc=rhel72 >> memberofindirect: cn=System: Manage Host >> Keytab,cn=permissions,cn=pbac,dc=rhel72 >> ... >> # kinit fbar >> # ipa-getkeytab -s `hostname` -k /tmp/fbar.keytab -p host/fbar.example.com >> Failed to parse result: Insufficient access rights >> >> Retrying with pre-4.0 keytab retrieval method... >> Keytab successfully retrieved and stored in: /tmp/fbar.keytab >> >> The keytab was created, but I wonder if this is expected and the >> I wonder if this is expected and "System: Manage Host Keytab: should not >> rather operate with ipaProtectedOperation. CCing Simo. > > It is not really expected, the fallback was made to allow a client to work > against an older server not to work "around" permission issues. > > The idea is to actually change the default permissions soon(*) so that the > *old* interface stops working by default and the admin has to enable it > intentionally in cn=etc config option if they still have older clients around > that need it. > > Simo. > > (*) I think we had a ticket, I would like it scheduled for 4.4 (I can implement > it) The closest ticket I found is: https://fedorahosted.org/freeipa/ticket/232 I updated it with the results of this discussion. The patch would be very welcome! Thank you, Martin From mkosek at redhat.com Thu Nov 12 19:55:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Nov 2015 20:55:25 +0100 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) In-Reply-To: References: <564497EE.9060702@redhat.com> Message-ID: <5644EEAD.9010608@redhat.com> On 11/12/2015 04:51 PM, Terry John wrote: > > I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. CCing Nalin and David for the core dump. More below. > > On 11/12/2015 02:17 PM, Terry John wrote: >>> I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. >>> My current version of ipa-server is 3.0.0-47 >>> Certmonger crashes with a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. > >> It of course should not crash, it would be useful to have a backtrace from the core file that was generated. > Here is the backtrace of the core file: > { "signal": 11 > , "executable": "/usr/sbin/certmonger" > , "stacktrace": > [ { "crash_thread": true > , "frames": > [ { "address": 140527158519285 > , "build_id": "87a19a61dc011579f3e25de3ca9778c6fd9e4547" > , "build_id_offset": 1222133 > , "function_name": "__strstr_sse42" > , "file_name": "/lib64/libc.so.6" > } > , { "address": 140527209363149 > , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" > , "build_id_offset": 141005 > , "file_name": "/usr/sbin/certmonger" > } > , { "address": 140527209301676 > , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" > , "build_id_offset": 79532 > , "file_name": "/usr/sbin/certmonger" > } > , { "address": 140527209287550 > , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" > , "build_id_offset": 65406 > , "file_name": "/usr/sbin/certmonger" > } > , { "address": 140527209291166 > , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" > , "build_id_offset": 69022 > , "file_name": "/usr/sbin/certmonger" > } > , { "address": 140527196303038 > , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" > , "build_id_offset": 36542 > , "file_name": "/usr/lib64/libtevent.so.0" > } > , { "address": 140527196295910 > , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" > , "build_id_offset": 29414 > , "file_name": "/usr/lib64/libtevent.so.0" > } > , { "address": 140527196279965 > , "build_id": "4135efbfc51bb80e4945275a6e6ba10e9d8a2a11" > , "build_id_offset": 13469 > , "function_name": "_tevent_loop_once" > , "file_name": "/usr/lib64/libtevent.so.0" > } > , { "address": 140527209278079 > , "build_id": "3a90011aabc8c2612ed5fe7e1249bec8438c72b3" > , "build_id_offset": 55935 > , "function_name": "main" > , "file_name": "/usr/sbin/certmonger" > } ] > } ] > } > > In /var/log/messages I get > freeipasvr kernel: certmonger[2611] general protection ip:7fb487fed5f5 sp:7ffd9df46898 error:0 in libc-2.12.so[7fb487ec3000+18a000] > > This is the first error I get in /var/log/httpd/error_log when I try to delete a host > [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): Unable to communicate with CMS (Service Unavailable) > >>> If I stop ipa the start certmonger it starts ok and continues to run when I start ipa again but as soon as any requests are made like "getcert list" then it crashes again. >>> With certmonger still running I can do a request >> >>> # ipa cert-status >>> Request id: 20140417164153 >>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>> communicate with CMS (Service Unavailable) # service certmonger status >>> certmonger (pid 3030) is running... > >> It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. > Yes ipa cert-show 1 does show the same thing > # ipa cert-show 1 > ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Unavailable) > >> Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. > I'm sure SELinux is not an issue. There are no AVC errors in /var/log/audit/audit.log and it fails the same way in 'Enforcing' and 'Permissive' modes > > I'm pretty certain the dogtag service is not running Then you have your lucky winner! :-) >> Some pointers to logs are for example here: >> http://www.freeipa.org/page/Troubleshooting#Server_Installation > > > /var/log/pki-ca/catalina.out contains the lines at boot time: > INFO: Deploying web application directory ca > Nov 12, 2015 3:33:47 PM org.apache.tomcat.util.modeler.Registry registerComponent > SEVERE: Null component Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/ca,J2EEApplication=none,J2EEServer=none > Nov 12, 2015 3:33:47 PM org.apache.catalina.startup.HostConfig deployDirectory > SEVERE: Error deploying web application directory ca > java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) > at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2334).... lots of traceback > > /var/log/pki-ca/system is empty > /var/log/pki-ca/debug has nothing new for 2 days CCing Fraser. This is a wild guess, but maybe you updated your java to java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS: https://bugzilla.redhat.com/show_bug.cgi?id=1262516 java would need to be switched with "alternate" to pre-1.8.0 version if this is the case. >>> This fault with the "Service Unavailable" originally came up when I >>> tried to delete a host from the freeip gui >>> In the file /var/log/dirsrv/slapd-PKI-IPA/errors file there was a Warning about nsslapd-cachememsize not being big enough but I don't know how to change it if, indeed this is anything to do with it. > >> This should not cause this error, it is more about performance tuning, AFAIK. > That's good to know.. > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > V:0CF72C13B2AC > > > From andrew.krause at breakthroughfuel.com Thu Nov 12 21:03:51 2015 From: andrew.krause at breakthroughfuel.com (Andrew Krause) Date: Thu, 12 Nov 2015 21:03:51 +0000 Subject: [Freeipa-users] 3/4 replica failure - unknown reasons why In-Reply-To: <56445006.50809@redhat.com> References: <9789D1C1-572F-4CB7-AE8D-26E07E94B1CB@breakthroughfuel.com> <56445006.50809@redhat.com> Message-ID: There were 0 networking issues. These errors reported for approximately 10 hours in logs, but there were no instances of connectivity loss. One of the replicas that experienced this issue is actually on the same physical hardware as the single node that had no issues. The errors continued to report constantly in logs from the start of the incident until I restarted freeIPA services. Replication immediately resumed and has had no such issue since. I?m fairly confident this also was not caused by load since the node that continued to work services 90% or more of our authentication requests. The other 3 nodes are basically just a hot standby. At this point we?re hoping it was a fluke, we?ve tightened our monitoring and awareness since we have no way to explain the root cause. > On Nov 12, 2015, at 2:38 AM, thierry bordaz wrote: > > On 11/11/2015 04:20 PM, Andrew Krause wrote: >> Yesterday I came in to 3 of my 4 freeipa replicas in an unusable state and replication was not connecting any of the hosts to each other. My first/primary host was still servicing authentication requests, but the others were in varying states of usability. I?ve investigated logs on all 4 nodes and the only thing I can see is messages like this from when the problem started until I restarted all 4 with ipactl stop/ipactl start: >> >> [09/Nov/2015:19:17:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:19:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:21:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:23:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:25:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:27:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:29:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:31:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:32:37 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Warning: Attempting to release replica, but unable to receive endReplication extended operation response from the replica. Error -5 (Timed out) >> [09/Nov/2015:19:33:29 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:34:37 -0700] NSMMReplicationPlugin - agmt="cn=meToa.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:35:28 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> [09/Nov/2015:19:36:41 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >> >> >> We?ve already looked into our network and there was no outage/interruption between sites during the timeframe in question. The only corrective action that was taken was to restart each node. Does anyone know any way I can investigate further what caused this issue? I don?t like giving ?I don?t know? answers for why replication stopped working and did not resume by itself. >> >> > Hi Andrew, > > There are quite periodic (each min or couple of min) networking issues where the primary host fails to process the replication protocol with bcloc[12]papp08. > There may be problem with the 3rd replica but it is present in this portion of logs. > Most of the time it prevents primary master to establish a replication session so these replica are likely late. > The replicas are reachable but do not answer fast enough and the protocol times out. > > Default replication timeout is 10m but can be tuned in each replica agreement nsds5ReplicaTimeout. > Is the value set ? > > As it was working fine before, it would be interesting to check the replica logs (may be enable replication logging for them) when the timeout occurs. > Also, if the problem continue take periodic (under the nsds5ReplicaTimeout value) pstacks of the replica because there may be something that make them busy and unable to answer fast enough. > > thanks > thierry From bcoates at liquidweb.com Thu Nov 12 21:57:08 2015 From: bcoates at liquidweb.com (Branden Coates) Date: Thu, 12 Nov 2015 16:57:08 -0500 Subject: [Freeipa-users] Sudo Rules Help In-Reply-To: <56445D12.6010203@redhat.com> References: <56434F97.40405@liquidweb.com> <56445D12.6010203@redhat.com> Message-ID: <56450B34.4070905@liquidweb.com> Thank you for the welcome! So in the process of pulling the output of the log files with the most recent attempts on cent6 I sorted out the issues with cent6, though cent5 is still problematic. I added debug_level = 6 to sudo and the domain in the sssd.conf. Originally I only had this for sudo so I was missing part of the puzzle. I also removed the lines as suggested from the sssd.conf since they are un-necessary. I suspect that may have been something that was a hold over from the migration process between an old d389 system using ldap.conf and freeipa. While I was cleansing the domain logs I could see all the ldap_ directives detected and the defaults if not defined in sssd.conf. Our setup does not allow anonymous access so a bind user is required to pull group info. I added the lines below knowing now that the binddn directive is invalid: ldap_default_bind_dn = ldap_default_authtok = to the sssd.conf for cent6, reloaded sssd and cleared its cache with sss_cache -E and attempted to sudo and it worked! After sorting that out I moved on to working with cent5, also adding the two lines above to its sssd.conf. I can now see in the logs that it finds the users groups and can match that up in the sudo rules but it is not finding the host in the host groups to match on the sudo rules. I am attaching the logs from cent5 to show the issue related here. The host I am testing on is a member of the host group called "sysops". You can see in the attached sudo_debug that it does find the sysops sudo rule, and also sees the host group called sysops assigned to the sudo rule, but it does not find the host within the group. Note that it prompts for a password, however the sudo rule does have the option !authenticate on the sysops sudo rule, so once it can find the host it should no longer prompt for a password. I appreciate your taking the time to give insight on this issue. I have been fighting with this for a few weeks now. On 11/12/2015 04:34 AM, Pavel B?ezina wrote: > On 11/11/2015 03:24 PM, Branden Coates wrote: >> I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) that I >> would greatly appreciate some help with. The core of the issue is that >> sudo rules fail to work when using ldap instead of ipa when you assign >> user groups and host groups to the sudo rule in place of explicitly >> adding users and hosts to the sudo rule. The reason for needing to use >> ldap over ipa is due to the organization requiring 2fa for all users via >> OTP tokens. We have a mix of cent 5 to 7 systems, not all can be >> immediately upgraded, so with cent 5 and 6 nodes ldap must be used >> instead of ipa to support 2fa. >> Explicitly assigning users and hosts to sudo rules is also unmanageable, >> the organization has hundreds of employees and multiple thousands of >> servers. Utilizing the host and user groups is a must. >> >> On cent 7 the default sssd.conf generated by FreeIPA works, 2fa works by >> default and the sssd.conf is using the ipa directives as well to parse >> user and host groups on sudo rules. Everything here works as expected. >> >> In cent 6 to allow 2fa to work the conf has to be updated to use ldap >> instead of ipa. In the process this seems to break the ability to search >> user and host groups on sudo rules. Users and hosts explicitly defined >> for the sudo rules still work so the clients can see the rules, they >> just do not seem to want to look within the groups that may be assigned >> to the rules. I moved the original sssd.conf created by FreeIPA using >> the ipa directives and sudo works as expected, but 2fa is not possible >> like this. >> >> Cent 5 is entirely incapable of using the sudo rules with user and host >> groups since sudo lacks sssd support in cent 5 and depends on >> /etc/ldap.conf to work. However like cent 6, users and hosts explicitly >> defined for the sudo rules still work, so I presume fixing the sudo >> rules with cent 6 on ldap would fix them here as well. >> >> Can anyone else confirm this behavior, and if so can anyone suggest any >> possible fixes or workarounds? I have attached the modified Cent6 and >> Cent 5 configs for sssd and ldap inline below(first time mailing, if >> inline is not ok please let me know what is preferable for future > > Hi, > welcome to the list! I personally prefer receiving it as an > attachment, since it is more convenient for me to organize and read. > >> reference). Currently testing using the following versions: >> CentOS Linux release 7.1.1503 (Core) >> CentOS release 6.7 (Final) >> CentOS release 5.11 (Final) >> >> Cent 6 /etc/sssd/sssd.conf: >> >> #SSSD client configuration file. >> [domain/domain] >> id_provider = ldap >> auth_provider = ldap >> chpass_provider = ldap >> autofs_provider = ldap >> sudo_provider = ldap > >> binddn = >> bindpw = >> scope = sub >> sudoers_base = ou=SUDOers,dc=,dc=com >> tls_cacertfile = /etc/ipa/ca.crt >> tls_checkpeer = yes >> tls_reqcert = demand >> ssl = start_tls > > ^ these are not sssd options thus it should not be in sssd.conf > >> >> ldap_schema = rfc2307bis >> ldap_uri = _srv_,ldap://.:389 >> ldap_search_base = dc=,dc=com >> ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com >> ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com >> ldap_sudo_search_base = ou=SUDOers,dc=,dc=com >> >> enumerate = True >> cache_credentials = True >> >> ldap_tls_cacertdir = /etc/ipa/ >> ldap_tls_cacert = /etc/ipa/ca.crt >> ldap_tls_reqcert = demand >> ldap_id_use_start_tls = True >> >> krb5_realm = > > I do not see anything wrong here at first sight. Can you send also > sssd_sudo.log and sssd_$domain.log please? > >> >> [sssd] >> services = nss, sudo, pam, ssh, autofs >> config_file_version = 2 >> domains = domain >> >> [nss] >> homedir_substring = /home >> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd >> >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> [ifp] >> >> >> Cent 5 /etc/sssd/sssd.conf: >> >> #SSSD client configuration file. >> [domain/domain] >> id_provider = ldap >> auth_provider = ldap >> chpass_provider = ldap >> autofs_provider = ldap >> >> ldap_schema = rfc2307bis >> ldap_uri = _srv_,ldap://.:389 >> ldap_search_base = dc=,dc=com >> ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com >> ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com >> >> enumerate = True >> cache_credentials = True >> >> ldap_tls_cacertdir = /etc/ipa/ >> ldap_tls_cacert = /etc/ipa/ca.crt >> ldap_tls_reqcert = demand >> ldap_id_use_start_tls = True >> >> krb5_realm = >> >> [sssd] >> services = nss, pam >> config_file_version = 2 >> domains = domain >> >> [nss] >> homedir_substring = /home >> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd >> >> [pam] >> >> >> Cent 5 /etc/ldap.conf: >> >> #LDAP client configuration file. >> uri ldap://.:389 >> base dc=,dc=com >> ldap_version 3 >> >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> ssl start_tls >> >> binddn >> bindpw >> timelimit 5 >> bind_timelimit 15 >> >> sudoers_base ou=SUDOers,dc=,dc=com >> >> >> Thank you >> Brande >> >> > -------------- next part -------------- [bcoates at cent5test3 ~]$ sudo su - LDAP Config Summary =================== uri ldap://.,:389 ldap_version 3 sudoers_base ou=SUDOers,dc=,dc=com binddn bindpw bind_timelimit 15000 timelimit 5 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_initialize(ld, ldap://.,:389) sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: timelimit -> 5 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 15) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: found:cn=defaults,ou=sudoers,dc=,dc=com sudo: ldap sudoOption: 'env_keep+=SSH_AUTH_SOCK' sudo: ldap sudoOption: 'requiretty' sudo: ldap sudoOption: 'always_set_home' sudo: ldap search '(|(sudoUser=bcoates)(sudoUser=%bcoates)(sudoUser=%default)(sudoUser=%supervisors)(sudoUser=%sysops)(sudoUser=ALL))' sudo: found:cn=default,ou=sudoers,dc=,dc=com sudo: ldap sudoHost '+backupservers' ... not sudo: ldap sudoHost '+internalservers' ... not sudo: found:cn=sysops,ou=sudoers,dc=,dc=com sudo: ldap sudoHost '+guardianservers' ... not sudo: ldap sudoHost '+idm-servers' ... not sudo: ldap sudoHost '+radius-servers' ... not sudo: ldap sudoHost '+sysops' ... not sudo: found:cn=supervisors,ou=sudoers,dc=,dc=com sudo: ldap sudoHost '+supervisorservers' ... not sudo: ldap search 'sudoUser=+*' sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x40 [sudo] password for bcoates: -------------- next part -------------- (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [be_get_account_info] (4): Got request for [3][1][name=bcoates] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(uid=bcoates)(objectclass=posixAccount))][cn=users,cn=accounts,dc=,dc=com]. (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_save_user] (6): Storing info for user bcoates (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_initgr_rfc2307bis_send] (6): Looking up parent groups for user [uid=bcoates,cn=users,cn=accounts,dc=,dc=com] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=uid=bcoates,cn=users,cn=accounts,dc=,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=,dc=com]. (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Processing group [default] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=default,cn=groups,cn=accounts,dc=,dc=com] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=default,cn=groups,cn=accounts,dc=,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=,dc=com]. (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Processing group [supervisors] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=supervisors,cn=groups,cn=accounts,dc=,dc=com] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=supervisors,cn=groups,cn=accounts,dc=,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=,dc=com]. (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Processing group [sysops] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=sysops,cn=groups,cn=accounts,dc=,dc=com] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=sysops,cn=groups,cn=accounts,dc=,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=,dc=com]. (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [be_pam_handler] (4): Got request with the following data (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): domain: (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): user: bcoates (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): service: sudo (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): tty: /dev/pts/1 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): ruser: (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): rhost: (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): authtok type: 1 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): authtok size: 0 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): newauthtok type: 0 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): newauthtok size: 0 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): priv: 0 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [pam_print_data] (4): cli_pid: 21973 (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [be_pam_handler_callback] (4): Backend returned: (0, 6, ) [Success] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [be_pam_handler_callback] (4): Sending result [6][] (Thu Nov 12 16:37:31 2015) [sssd[be[]]] [be_pam_handler_callback] (4): Sent result [6][] From jcnt at use.startmail.com Thu Nov 12 23:13:04 2015 From: jcnt at use.startmail.com (jcnt at use.startmail.com) Date: Thu, 12 Nov 2015 18:13:04 -0500 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: References: Message-ID: <50d162a6afd22e9e3357e5f20ecdca37.startmail@www.startmail.com> On Mon, 9 Nov 2015 08:53:34 +0100, Petr Spacek wrote: > > What do you mean, exactly, by 'stand alone NFS server'? > > Is it another server which did not executed ipa-client-install? Correct, another server, which didn't execute ipa-client-install. I created host principal and nfs principal as instructed in section 16.3.1 copied nfs principal and verified that kinit -k nfs/nfsserver.example.org works and krbtgt stored in Ticket cache. So how does one enable sufficient verbosity to debug kerberos nfs problems? Regards, Josh. From prashant at apigee.com Fri Nov 13 04:36:09 2015 From: prashant at apigee.com (Prashant Bapat) Date: Fri, 13 Nov 2015 10:06:09 +0530 Subject: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 In-Reply-To: <56435E3D.4060605@redhat.com> References: <56431F2D.5060404@physik.uni-wuppertal.de> <56435E3D.4060605@redhat.com> Message-ID: Is there a way for you to try F23. Its the latest anyway if thats the reason you're upgrading. I recently did this couple of times in a test setup (aws and virtualbox). I have 4.1.4 (F21) in production. Was trying upgrade from F21->F22 and F22->F23 this would give me freeipa 4.2.3.? Things went very smoothly for me. Make sure you do a dnf update freeipa-server after you're in F23. On 11 November 2015 at 20:56, Martin Basti wrote: > > > On 11.11.2015 11:57, Torsten Harenberg wrote: > >> Dear all, >> >> on our secondary IPA server (running 4.1.4) we did an upgrade of FC from >> 21 to 22, as 21 is running out of support. >> >> The upgrade process itself went smoothly, however, 386DS segfaults now: >> >> ns-slapd[1427]: segfault at 7fffe301413e ip 00007fffeeb1fa08 sp >> 00007fffffffd3d8 error 4 in libdb-5.3.so[7fffee9fa000+1b8000] >> >> every time it is started. >> >> This does not seem to be the problem reported earlier with IPA 4.2 on FC >> 23 (that segfaulted in libslapd). >> >> I couldn't get a hint out of the strace output. But the packages in >> question are: >> >> [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /lib64/libdb-5.3.so >> libdb-5.3.28-12.fc22.x86_64 >> [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# rpm -qf /usr/sbin/ns-slapd >> 389-ds-base-1.3.4.4-1.fc22.x86_64 >> [root at ipa2 slapd-PLEIADES-UNI-WUPPERTAL-DE]# >> >> >> Any hint is appreciated!!! >> >> Best regards >> >> Torsten >> >> Hello, > can you provide traceback? > > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes > > Martin > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Nov 13 07:47:42 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Nov 2015 08:47:42 +0100 Subject: [Freeipa-users] problems with NFS service principal In-Reply-To: <50d162a6afd22e9e3357e5f20ecdca37.startmail@www.startmail.com> References: <50d162a6afd22e9e3357e5f20ecdca37.startmail@www.startmail.com> Message-ID: <5645959E.8090004@redhat.com> On 13.11.2015 00:13, jcnt at use.startmail.com wrote: > > > On Mon, 9 Nov 2015 08:53:34 +0100, Petr Spacek wrote: >> >> What do you mean, exactly, by 'stand alone NFS server'? >> >> Is it another server which did not executed ipa-client-install? > > Correct, another server, which didn't execute ipa-client-install. > I created host principal and nfs principal as instructed in section 16.3.1 > copied nfs principal and verified that > kinit -k nfs/nfsserver.example.org works and krbtgt stored in Ticket cache. > > So how does one enable sufficient verbosity to debug kerberos nfs problems? Have you seen howtos linked from http://www.freeipa.org/page/HowTos#Authentication ? -- Petr Spacek @ Red Hat From tbordaz at redhat.com Fri Nov 13 08:30:38 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 13 Nov 2015 09:30:38 +0100 Subject: [Freeipa-users] 3/4 replica failure - unknown reasons why In-Reply-To: References: <9789D1C1-572F-4CB7-AE8D-26E07E94B1CB@breakthroughfuel.com> <56445006.50809@redhat.com> Message-ID: <56459FAE.8080807@redhat.com> Hi Andrew, The primary was able to reach the replicas so I agree there is no networking issue. But the fact that the replicas did not answered in a given delay to the primary master, is seen by the primary master as a network issue and then it backoff for some time. Unless the timeout is incorrectly tuned (I doubt), I think the problem came from the replicas. For some reasons they are not responding fast enough. There is no obvious reason for that. Periodic pstacks of the replicas if the problem happens again, would likely give us the culprit. thanks thierry On 11/12/2015 10:03 PM, Andrew Krause wrote: > There were 0 networking issues. These errors reported for approximately 10 hours in logs, but there were no instances of connectivity loss. One of the replicas that experienced this issue is actually on the same physical hardware as the single node that had no issues. The errors continued to report constantly in logs from the start of the incident until I restarted freeIPA services. Replication immediately resumed and has had no such issue since. I?m fairly confident this also was not caused by load since the node that continued to work services 90% or more of our authentication requests. The other 3 nodes are basically just a hot standby. At this point we?re hoping it was a fluke, we?ve tightened our monitoring and awareness since we have no way to explain the root cause. > > >> On Nov 12, 2015, at 2:38 AM, thierry bordaz wrote: >> >> On 11/11/2015 04:20 PM, Andrew Krause wrote: >>> Yesterday I came in to 3 of my 4 freeipa replicas in an unusable state and replication was not connecting any of the hosts to each other. My first/primary host was still servicing authentication requests, but the others were in varying states of usability. I?ve investigated logs on all 4 nodes and the only thing I can see is messages like this from when the problem started until I restarted all 4 with ipactl stop/ipactl start: >>> >>> [09/Nov/2015:19:17:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:19:16 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:21:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:23:19 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:25:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:27:21 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:29:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:31:26 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:32:37 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Warning: Attempting to release replica, but unable to receive endReplication extended operation response from the replica. Error -5 (Timed out) >>> [09/Nov/2015:19:33:29 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:34:37 -0700] NSMMReplicationPlugin - agmt="cn=meToa.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:35:28 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc1papp08.somedomain.com" (abcloc1papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> [09/Nov/2015:19:36:41 -0700] NSMMReplicationPlugin - agmt="cn=meToabcloc2papp08.somedomain.com" (abcloc2papp08:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. >>> >>> >>> We?ve already looked into our network and there was no outage/interruption between sites during the timeframe in question. The only corrective action that was taken was to restart each node. Does anyone know any way I can investigate further what caused this issue? I don?t like giving ?I don?t know? answers for why replication stopped working and did not resume by itself. >>> >>> >> Hi Andrew, >> >> There are quite periodic (each min or couple of min) networking issues where the primary host fails to process the replication protocol with bcloc[12]papp08. >> There may be problem with the 3rd replica but it is present in this portion of logs. >> Most of the time it prevents primary master to establish a replication session so these replica are likely late. >> The replicas are reachable but do not answer fast enough and the protocol times out. >> >> Default replication timeout is 10m but can be tuned in each replica agreement nsds5ReplicaTimeout. >> Is the value set ? >> >> As it was working fine before, it would be interesting to check the replica logs (may be enable replication logging for them) when the timeout occurs. >> Also, if the problem continue take periodic (under the nsds5ReplicaTimeout value) pstacks of the replica because there may be something that make them busy and unable to answer fast enough. >> >> thanks >> thierry From oliver at doerr-privat.de Fri Nov 13 08:43:18 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Fri, 13 Nov 2015 09:43:18 +0100 Subject: [Freeipa-users] REST/JSON API: Howto add a user that is not expired In-Reply-To: <56448637.1070108@redhat.com> References: <564350B2.4090206@doerr-privat.de> <56435756.1030404@doerr-privat.de> <20151111151314.GF1147@redhat.com> <56448637.1070108@redhat.com> Message-ID: <5645A2A6.6090509@doerr-privat.de> Hi Petr, thanks for your hint. It works now. I've decided to change first the password to a random pasword as admin using user_mod and afterwards my code is using ipa/session/change_password to set the password to the final one. So I added this to my Perl module and I'm calling the code using... $ipaClient->changePasswordAsAdmin({'uid' =>'k812339', 'newPassword' => 'start123', 'doNotExpire' => 'true'}); Greetings Oliver Am 12.11.2015 um 13:29 schrieb Petr Vobornik: > On 11/11/2015 04:13 PM, Alexander Bokovoy wrote: >> On Wed, 11 Nov 2015, Oliver D?rr wrote: >>> Hi, >>> >>> i've tried user_mod instead because of >>> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html >>> >>> and got >>> >>> Error-code: 2100 >>> Error-name: ACIError >>> Error-msg: Insufficient access: Insufficient 'write' privilege to >>> the 'krbPasswordExpiration' attribute of entry >>> 'uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de'. >>> >>> Inside the acces log of the LDAP Server I could see... >>> >>> [09/Nov/2015:18:40:31 +0100] conn=658 op=7 MOD >>> dn="uid=k812339,cn=users,cn=accounts,dc=kreditwerk,dc=de" >>> [09/Nov/2015:18:40:31 +0100] conn=658 op=7 RESULT err=50 tag=103 >>> nentries=0 etime=0 >>> >>> So it looks like it is a permission issue. But I still have the >>> problem when use admin to do the job. Any idea about how to change the >>> permission or an API that it is able to do the job? >> You simply cannot make it working for cases when a password change >> coming from a non-user. This is intentional. >> >> See http://www.freeipa.org/page/New_Passwords_Expired >> >> You can do double change via LDAP password change (or Kerberos) where >> you changre a >> password first to something temporary, then try to change it again as a >> user with that temporary password and set a new one. Since the second >> change would be done as a user, that should allow the change to happen >> without raising a flag. > > You can use ipa/session/change_password call for that. With > > Content-Type:application/x-www-form-urlencoded > > and e.g.: > > user:bbar > old_password:a > new_password:b > > Web UI uses it when user with expired password is resetting his pw. So > you can check the communication in browser network tab. > > >>> >>> Thanks in advance >>> Oliver >>> >>> Am 11.11.2015 um 15:29 schrieb Oliver D?rr: >>>> Hi, >>>> >>>> i'm still working with the JSON API and I now have the problem, that >>>> I want to add a user with a not expired password. I've tried setattr >>>> and addattr with the following JSON code, but both fail. >>>> {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","addattr":"krbpasswordexpiration=20160207010919Z","cn":"Oliver >>>> >>>> Support","sn":"Support"}],"id":0,"method":"user_add"} >>>> >>>> >>>> {"params":[[],{"givenname":"Oliver","userpassword":"start123","uid":"k812339","version":"2.151","cn":"Oliver >>>> >>>> Support","setattr":"krbpasswordexpiration=20160207010919Z","sn":"Support"}],"id":0,"method":"user_add"} >>>> >>>> >>>> >>>> >>>> >>>> The user is added to IPA, but the user is still forced to change it's >>>> password. In the response I could see that my krbpasswordexpiration >>>> is ignored. >>>> >>>> Any ideas what I'm doing wrong? >>>> >>>> Thanks >>>> Oliver >>>> >>> >>> -- >>> 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 >> > > -------------- next part -------------- package freeipa; use strict; use REST::Client; use JSON; use Encode; use Data::Dumper; our $VERSION="0.0.2"; BEGIN { }; sub new # Constructor of the class freeipa { my ($Class)=@_; my $self= {}; bless($self,$Class); $self->{'id'}=0; # id is a unique numeric identifier for the product. Red Hat uses 0. return $self; } # sub news sub set # Setter of the class freeipa. At this moment only usuable or scalar values { my $ipaObj=shift; my $scalar=shift; my $value=shift; # Should we use the API-version from the server environment ? if ($scalar eq 'version' && $value eq 'env') { my $retObj=$ipaObj->ipaMethod({'method' => 'env'}); if (! $retObj->{'error'} && ($retObj->{'result'}->{'result'}->{'api_version'})) { $value=$retObj->{'result'}->{'result'}->{'api_version'}; } } # if ($scalar eq 'version' && $value eq 'env') $ipaObj->{$scalar}=$value; } # sub set sub error # This method prints out the error messages and exit 1 if configured. { my $ipaObj=shift; print "Error-code:\t".$ipaObj->{"errCode"}."\n"; print "Error-name:\t".$ipaObj->{"errName"}."\n"; print "Error-msg:\t".$ipaObj->{"errMsg"}."\n"; if ($ipaObj->{'dieOnError'}) { exit 1; } } # sub error sub changePasswordAsUser # Connects to the specified IPA server via REST and changes the password of the specified user. # You have to provide the old and the new password { my $ipaObj=shift; my $paramRef=shift; my $headers = { 'Accept' => 'text/plain', 'Content-Type' => 'application/x-www-form-urlencoded', 'Referer' => $ipaObj->{'baseUrl'} }; # my $headers my $client=REST::Client->new(); my $params = $client->buildQuery({'user' => $paramRef->{'uid'}, 'old_password' => $paramRef->{'oldPassword'}, 'new_password' => $paramRef->{'newPassword'}}); $client->setHost($ipaObj->{'baseUrl'}); $client->POST("/ipa/session/change_password", substr($params,1), $headers); # Change was not succesful if ($client->responseCode() != 200) { $ipaObj->{"errCode"} = $client->responseCode(); $ipaObj->{"errName"} = "HTTP error"; $ipaObj->{"errMsg"} = $client->responseContent(); $ipaObj->error(); } else { # Policy violations also have the responseCode == 200 and so we have to take a closer look if ($client->responseContent() =~ /rejected/) { $ipaObj->{"errCode"} = $client->responseCode(); $ipaObj->{"errName"} = "Policy violation"; $ipaObj->{"errMsg"} = $client->responseContent(); $ipaObj->error(); } # if ($client->responseContent() =~ /rejected/) } # if ($client->responseCode() != 200) } # sub changePasswordAsUser sub changePasswordAsAdmin # Connects to the specified IAP server via REST/JSON as an admin and # sets the password of the user. You need to specifiy uid and an optional # new password. There is a randon password generated, if you do not sepcify # a new one. Using the option 'doNotExpire' you could get a password that # is not expred. Please notice that the IPA will set the new password to # expired, if doNotExpire is not specified. { my $ipaClient=shift; my $paramRef=shift; my $ipaParam={}; my $newPassword=$paramRef->{'newPassword'}; my $oldPassword=$newPassword; # Set the new password either well by the caller or random $ipaParam->{'uid'}=$paramRef->{'uid'}; if ($newPassword && ! $paramRef->{'doNotExpire'}) {$ipaParam->{'userpassword'}=$newPassword} else { $ipaParam->{'random'}="true"; } my $retObj=$ipaClient->ipaMethod({'method' => 'user_mod'}, $ipaParam); if ($ipaParam->{'random'}) { $oldPassword=$retObj->{'result'}->{'result'}->{'randompassword'}; } # The password should not be expired and so we have to change it as user if ($paramRef->{'doNotExpire'}) { $ipaClient->changePasswordAsUser({'uid' =>$paramRef->{'uid'}, 'oldPassword'=>$oldPassword, 'newPassword'=>$newPassword}); } return $retObj->{'result'}->{'result'}->{'randompassword'}; } # sub changePasswordAsAdmin sub connect # Connects to the specified IPA server { my $ipaObj=shift; my $headers = { 'Accept' => 'text/plain', 'Content-Type' => 'application/x-www-form-urlencoded', 'Referer' => $ipaObj->{'baseUrl'} }; # my $headers my $client=REST::Client->new(); my $params = $client->buildQuery({'user' => $ipaObj->{'user'}, 'password' => $ipaObj->{'password'} }); $client->setHost($ipaObj->{'baseUrl'}); $client->POST("/ipa/session/login_password", substr($params,1), $headers); # Login was not succesful if ($client->responseCode() != 200) { $ipaObj->{"errCode"} = $client->responseCode(); $ipaObj->{"errName"} = "HTTP error"; $ipaObj->{"errMsg"} = $client->responseContent(); $ipaObj->error(); } else { $ipaObj->{'authCookie'} = $client->responseHeader('Set-Cookie'); $ipaObj->{'restClient'}=$client; } # if ($client->responseCode() != 200) } # sub connect sub ipaMethod # Calls an API method against the IPA connection { my $ipaObj=shift; my $hashRef=shift; my $paramRef=shift; # create the parameter hash for the API call, version will be filled by default, all others # came from the parameter reference that we got by calling the ipaMethod my $paramHash={}; if ($ipaObj->{'version'}) { $paramHash = { 'version' => $ipaObj->{'version'} }; } foreach my $param (keys (%{$paramRef})) { $paramHash->{$param} = $paramRef->{$param}; } # We need data and header for the JSON request against the IPA API my $data = { 'id'=>$ipaObj->{'id'}, 'params' => [ [], $paramHash ] }; # my $data my $headers = { 'Accept' => 'text/plain', 'Content-Type' => 'application/json', 'Cookie' => $ipaObj->{'authCookie'}, 'Referer' => $ipaObj->{'baseUrl'}."/ipa/session/json" }; # Copy the specified part of the method over the default data defined in $data foreach my $var (keys (%{$hashRef})) { $data->{$var}=$hashRef->{$var}; } # Format the method and data to json and make a REST request against the IPA server my $jsonRequest = encode_json($data); if ($ipaObj->{'debug'}->{'printJsonRequest'}) { print "JSON-Request: ".$jsonRequest."\n"; } $ipaObj->{'restClient'}->POST("/ipa/session/json", decode("utf8",$jsonRequest), $headers); # bring the JSON-formed response into perl objects... my $jsonReponse = $ipaObj->{'restClient'}->responseContent(); if ($ipaObj->{'debug'}->{'printJsonResponse'}) { print "JSON-Response: ".$jsonReponse."\n"; } my $restRet=decode_json($jsonReponse); # Minimal error handling if ($restRet->{"error"}) { $ipaObj->{"errCode"} = $restRet->{"error"}->{"code"}; $ipaObj->{"errMsg"} = $restRet->{"error"}->{'message'}; $ipaObj->{"errName"} = $restRet->{"error"}->{'name'}; $ipaObj->error(); } # if ($restRet->{"error"}) # ... and return these return $restRet; } # sub ipaMethod From Terry.John at completeautomotivesolutions.co.uk Fri Nov 13 10:14:28 2015 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Fri, 13 Nov 2015 10:14:28 +0000 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved) Message-ID: >On 11/12/2015 04:51 PM, Terry John wrote: >> I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. >CCing Nalin and David for the core dump. More below. > On 11/12/2015 02:17 PM, Terry John wrote: >>> I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. >>> My current version of ipa-server is 3.0.0-47 Certmonger crashes with >>> a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. > >>>> # ipa cert-status >>>> Request id: 20140417164153 >>>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>>> communicate with CMS (Service Unavailable) # service certmonger >>>> status certmonger (pid 3030) is running... >> >>> It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. >> Yes ipa cert-show 1 does show the same thing # ipa cert-show 1 >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (Service Unavailable) >> >>> Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. >> I'm pretty certain the dogtag service is not running Then you have your lucky winner! :-) >>> Some pointers to logs are for example here: >>> http://www.freeipa.org/page/Troubleshooting#Server_Installation > >> /var/log/pki-ca/catalina.out contains the lines at boot time: >> SEVERE: Error deploying web application directory ca >> java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> lassLoader.java:2334).... lots of traceback >> >> /var/log/pki-ca/system is empty >> /var/log/pki-ca/debug has nothing new for 2 days >CCing Fraser. This is a wild guess, but maybe you updated your java to java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS: >https://bugzilla.redhat.com/show_bug.cgi?id=1262516 >java would need to be switched with "alternate" to pre-1.8.0 version if this is the case. The java version was the problem. Luckily I have a java expert to hand and explained that major.minor version 51.0 corresponds to java 7 http://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers When I did # ps ax | grep java I got" 1460 ? Sl 1:21 /usr/java/default/bin/java -Djavax.sql.Da....... # /usr/java/default/bin/java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the /usr/java/default/bin is all from java-1.6.0-openjdk I have renamed /usr/java/default/bin/java to javaold and done # ln -s /usr/bin/java /usr/java/default/bin/java # /usr/java/default/bin/java -version java version "1.7.0_91" OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00) OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode) After a reboot FreeIPA works properly which is great but I'm wondering if there is a better fix though since all the other executables in are from the 1.6 version. I can't find a corresponding location for 1.7 executables. Thanks very much The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC From mkosek at redhat.com Fri Nov 13 11:00:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Nov 2015 12:00:16 +0100 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved) In-Reply-To: References: Message-ID: <5645C2C0.7090806@redhat.com> On 11/13/2015 11:14 AM, Terry John wrote: >> On 11/12/2015 04:51 PM, Terry John wrote: >>> I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. > >> CCing Nalin and David for the core dump. More below. > >> On 11/12/2015 02:17 PM, Terry John wrote: >>>> I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. >>>> My current version of ipa-server is 3.0.0-47 Certmonger crashes with >>>> a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. >> > > >>>>> # ipa cert-status >>>>> Request id: 20140417164153 >>>>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>>>> communicate with CMS (Service Unavailable) # service certmonger >>>>> status certmonger (pid 3030) is running... >>> >>>> It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. >>> Yes ipa cert-show 1 does show the same thing # ipa cert-show 1 >>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>> communicate with CMS (Service Unavailable) >>> >>>> Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. >>> I'm pretty certain the dogtag service is not running > > Then you have your lucky winner! :-) > >>>> Some pointers to logs are for example here: >>>> http://www.freeipa.org/page/Troubleshooting#Server_Installation >> >>> /var/log/pki-ca/catalina.out contains the lines at boot time: > > >>> SEVERE: Error deploying web application directory ca >>> java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> lassLoader.java:2334).... lots of traceback >>> >>> /var/log/pki-ca/system is empty >>> /var/log/pki-ca/debug has nothing new for 2 days > >> CCing Fraser. This is a wild guess, but maybe you updated your java to java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1262516 > >> java would need to be switched with "alternate" to pre-1.8.0 version if this is the case. > > The java version was the problem. Good! Fraser, can we improve anything in pki-core, so that wrong java version issue like this one does not occur? IIRC, pki-core in RHEL-6.x was updated to somehow deal with java 1.8.0 (conflict), not sure if lower versions are also covered. > Luckily I have a java expert to hand and explained that major.minor version 51.0 corresponds to java 7 > http://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers > When I did > # ps ax | grep java I got" > 1460 ? Sl 1:21 /usr/java/default/bin/java -Djavax.sql.Da....... > # /usr/java/default/bin/java -version > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b04) > Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) > > I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the /usr/java/default/bin is all from java-1.6.0-openjdk > > I have renamed /usr/java/default/bin/java to javaold and done > # ln -s /usr/bin/java /usr/java/default/bin/java > # /usr/java/default/bin/java -version > java version "1.7.0_91" > OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00) > OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode) This may work, but looks a bit hacky. I think the right way is to use "alternate" program I mentioned earlier to let you choose the right version of the java executable and/or libraries. > After a reboot FreeIPA works properly which is great but I'm wondering if there is a better fix though since all the other executables in are from the 1.6 version. I can't find a corresponding location for 1.7 executables. The "alternate" approach should "just work". I am glad you made the instance working again! > > Thanks very much > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > V:0CF72C13B2AC > > From Christopher.Gronde at fincen.gov Fri Nov 13 13:20:27 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Fri, 13 Nov 2015 13:20:27 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5644BB0D.3030209@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> <5644AE5E.2020106@redhat.com> <5644B531.3040507@jmips.co.uk> <5644BB0D.3030209@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828DA2C@hqexdb01.hqfincen.gov> For those of you that have been helping me...thank you! For all those following along here is the status of my issues. I ended up replacing the krbprincipal key and the user certificate in LDAP to match what is on the master and I am no longer getting the invalid credentials error! So thanks for that! Unfortunately, krb5kdc still will not start... When trying to run: ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-ITMODEV-GOV.socket -b "cn=ITMODEV.GOV,cn=kerberos,dc=itmodev,dc=gov" krbMKey=* I get " ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) " So we did a strace on that to see if we could find anything and I found: connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/slapd-ITMODEV-GOV.socket"}, 110) = -1 ECONNREFUSED (Connection refused) So it looks like an issue with the listening socket. Ran some more tests on the socket... [root at comipa02 ~]# ls -lZ /var/run/slapd-ITMODEV-GOV.socket srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-ITMODEV-GOV.socket So the socket exists but " lsof -U -a -udirsrv" gives me no return...nothing. Anybody know what I need to do to fix the socket? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Thursday, November 12, 2015 11:15 AM To: James Masson ; Martin Kosek ; freeipa-users at redhat.com; Jan Cholasta ; David Kupka ; Endi Sukma Dewata Subject: Re: [Freeipa-users] IPA with external CA signed certs James Masson wrote: > > > On 12/11/15 15:21, Rob Crittenden wrote: >> James Masson wrote: >>> >>> >>> On 30/10/15 13:52, Rob Crittenden wrote: >>>> James Masson wrote: >>>>> >>>>> >>>>> On 26/10/15 16:11, Martin Kosek wrote: >>>>>> On 10/26/2015 04:05 PM, James Masson wrote: >>>>>>> >>>>>>> >>>>>>> On 19/10/15 21:06, Rob Crittenden wrote: >>>>>>>> James Masson wrote: >>>>>>>>> >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I successfully have IPA working with CA certs signed by an >>>>>>>>> upstream Dogtag. >>>>>>>>> >>>>>>>>> Now I'm trying to use a CA cert signed by a different type of >>>>>>>>> CA - Vault. >>>>>>>>> >>>>>>>>> Setup fails, using the same 2 step IPA setup process as used >>>>>>>>> with upstream Dogtag. I've also tried the external-ca-type option. >>>>>>>>> >>>>>>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>>>>>> pinpoint why. >>>>>>>> >>>>>>>> I'm guessing you don't include the entire CA certchain of Vault. >>>>>>>> Dogtag >>>>>>>> is failing to startup because it can't verify its own cert chain: >>>>>>>> >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> CAPresence: CA is present >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> SystemCertsVerification: system certs verification failure >>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>>>>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>>>>>> selftests.container.instance.SystemCertsVerification running at >>>>>>>> startup FAILED! >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Rob, >>>>>>> >>>>>>> Thanks for the reply. >>>>>>> >>>>>>> I do present the IPA installer with both the CA and the IPA cert >>>>>>> - the IPAs python-based install code is happy with the cert >>>>>>> chain, but the Java based dogtag code chokes on it. >>>>>>> >>>>>>> OpenSSL is happy with it too. >>>>>>> >>>>>>> ##### >>>>>>> [root at foo ~]# openssl verify ipa.crt >>>>>>> ipa.crt: O = LOCAL, CN = Certificate Authority error 20 at 0 >>>>>>> depth lookup:unable to get local issuer certificate >>>>>>> >>>>>>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>>>>>> ipa.crt: OK >>>>>>> ### >>>>>>> >>>>>>> Any hints on how to reproduce this with more debug output? I'd >>>>>>> like to know exactly what Dogtag doesn't like about the >>>>>>> certificate. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> James M >>>>>> >>>>>> Let me CC at least Jan Ch. and David, they may be able to help >>>>>> and should also make sure FreeIPA gets better in validating the >>>>>> certs, as appropriate. >>>>>> >>>>> >>>>> Any thoughts guys? >>>> >>>> I cc'd one of the dogtag guys to see if he knows. >>>> >>>> You might also try using certutil to validate the certificates, it >>>> might give you some hints to what is going on. >>>> >>>> I'm assuming your certdb (it can vary by version) is in >>>> /var/lib/pki/pki-tomcat/alias >>>> >>>> certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list >>>> of certificates installed. You can verify each one to see what is >>>> going on. >>>> The -u flag specfies usage. See the certutil man page for a full >>>> set of options. >>>> >>>> For example: >>>> >>>> # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>>> 'auditSigningCert cert-pki-ca' >>>> certutil: certificate is valid >>>> >>>> rob >>>> >>> >>> Hi All, >>> >>> I've created a ticket to track this >>> >>> https://fedorahosted.org/pki/ticket/1697 >>> >>> Rob - certutil output: >>> >>> Some certificates types seem not to be approved. Not sure if this is >>> a red herring. >>> >>> ############## >>> [root at foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias >>> >>> Certificate Nickname Trust >>> Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> >>> caSigningCert cert-pki-ca CTu,Cu,Cu >>> root.com CT,c, >>> ocspSigningCert cert-pki-ca u,u,u >>> subsystemCert cert-pki-ca u,u,u >>> Server-Cert cert-pki-ca u,u,u >>> auditSigningCert cert-pki-ca u,u,Pu >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'caSigningCert cert-pki-ca' >>> certutil: certificate is valid >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'root.com' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'ocspSigningCert cert-pki-ca' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'subsystemCert cert-pki-ca' >>> certutil: certificate is valid >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'Server-Cert cert-pki-ca' >>> certutil: certificate is invalid: Certificate type not approved for >>> application. >>> [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n >>> 'auditSigningCert cert-pki-ca' >>> certutil: certificate is valid >>> ############# >> >> That's why I pointed you to the certutil man page to find out the >> differnet usages to test. The C usage is SSL client usage. Depending >> on the cert the usage may be different. >> >> rob > > Missed that. Here are those commands again with different certusage > checking > > In short, they're all superficially valid. > > ########## > [root at foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n > 'root.com' > certutil: certificate is valid > > > [root at foo ~]# certutil -V -u O -d /var/lib/pki/pki-tomcat/alias -n > 'ocspSigningCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n > 'subsystemCert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n > 'Server-Cert cert-pki-ca' > certutil: certificate is valid > > [root at foo ~]# certutil -V -u J -d /var/lib/pki/pki-tomcat/alias -n > 'auditSigningCert cert-pki-ca' > certutil: certificate is valid > #### > > > However, the debug logs seem to indicate the 'caSigningCert cert-pki-ca' > is the one it has problems with. > > #### > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=signing > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByTag(signing) > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(caSigningCert cert-pki-ca,SSLCA) > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed: caSigningCert cert-pki-ca > [12/Nov/2015:12:41:35][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcom > e=Failure][CertNickName=caSigningCert > cert-pki-ca] CIMC certificate verification ######### > > But further checking seems to indicate the cert passes the relevant > checks ( Y A L ) > > ###### > [root at foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u A -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > [root at foo ~]# certutil -V -u L -d /var/lib/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca' > certutil: certificate is valid > ##### > Ok, yeah, we'll need to wait for the dogtag guys to chime in here or on the ticket. Note that validity also depends on valid to/from dates so you might check that too, but it's a stretch to suggest that's the problem. 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 From harenberg at physik.uni-wuppertal.de Fri Nov 13 13:53:13 2015 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Fri, 13 Nov 2015 14:53:13 +0100 Subject: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 In-Reply-To: References: <56431F2D.5060404@physik.uni-wuppertal.de> <56435E3D.4060605@redhat.com> Message-ID: <5645EB49.8020507@physik.uni-wuppertal.de> Dear all, Am 13.11.15 um 05:36 schrieb Prashant Bapat: > Is there a way for you to try F23. Its the latest anyway if thats the > reason you're upgrading. > > I recently did this couple of times in a test setup (aws and > virtualbox). I have 4.1.4 (F21) in production. Was trying upgrade from > F21->F22 and F22->F23 this would give me freeipa 4.2.3.? Things went > very smoothly for me. > > Make sure you do a dnf update freeipa-server after you're in F23. > We tried also upgrading through to F23, the problem was still there. But our goal was to move to CentOS 7 anyhow to avoid too many OS updates. So we started installing a 4.1.4 IPA on CentOS 7 just today. That went smoothly so far :) Best regards, Torsten -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> <> Bergische Universitaet <> <> FB C - Physik Tel.: +49 (0)202 439-3521 <> <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> <> 42097 Wuppertal <> <> <> <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> From gparente at redhat.com Fri Nov 13 14:09:32 2015 From: gparente at redhat.com (German Parente) Date: Fri, 13 Nov 2015 09:09:32 -0500 (EST) Subject: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 In-Reply-To: <5645EB49.8020507@physik.uni-wuppertal.de> References: <56431F2D.5060404@physik.uni-wuppertal.de> <56435E3D.4060605@redhat.com> <5645EB49.8020507@physik.uni-wuppertal.de> Message-ID: <2105872570.9669258.1447423772498.JavaMail.zimbra@redhat.com> Hi Torsten, is it possible to provide a core or stacktrace ? http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes Thanks and regards, German. ----- Original Message ----- > From: "Torsten Harenberg" > To: freeipa-users at redhat.com > Sent: Friday, November 13, 2015 1:53:13 PM > Subject: Re: [Freeipa-users] 389DS segfaults after upgrade FC 21 -> 22 > > Dear all, > > Am 13.11.15 um 05:36 schrieb Prashant Bapat: > > Is there a way for you to try F23. Its the latest anyway if thats the > > reason you're upgrading. > > > > I recently did this couple of times in a test setup (aws and > > virtualbox). I have 4.1.4 (F21) in production. Was trying upgrade from > > F21->F22 and F22->F23 this would give me freeipa 4.2.3.? Things went > > very smoothly for me. > > > > Make sure you do a dnf update freeipa-server after you're in F23. > > > > We tried also upgrading through to F23, the problem was still there. > > But our goal was to move to CentOS 7 anyhow to avoid too many OS > updates. So we started installing a 4.1.4 IPA on CentOS 7 just today. > That went smoothly so far :) > > Best regards, > > Torsten > > > -- > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> > <> <> > <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> > <> Bergische Universitaet <> > <> FB C - Physik Tel.: +49 (0)202 439-3521 <> > <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> > <> 42097 Wuppertal <> > <> <> > <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> > > -- > 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 From rcritten at redhat.com Fri Nov 13 14:28:59 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Nov 2015 09:28:59 -0500 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <2909CC7109523F4BA968E7A201471B771828DA2C@hqexdb01.hqfincen.gov> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> <5644AE5E.2020106@redhat.com> <5644B531.3040507@jmips.co.uk> <5644BB0D.3030209@redhat.com> <2909CC7109523F4BA968E7A201471B771828DA2C@hqexdb01.hqfincen.gov> Message-ID: <5645F3AB.8060100@redhat.com> Gronde, Christopher (Contractor) wrote: > For those of you that have been helping me...thank you! For all those following along here is the status of my issues. > > I ended up replacing the krbprincipal key and the user certificate in LDAP to match what is on the master and I am no longer getting the invalid credentials error! So thanks for that! > > Unfortunately, krb5kdc still will not start... > > When trying to run: > > ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-ITMODEV-GOV.socket -b "cn=ITMODEV.GOV,cn=kerberos,dc=itmodev,dc=gov" krbMKey=* > > I get " ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) " > > So we did a strace on that to see if we could find anything and I found: > > connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/slapd-ITMODEV-GOV.socket"}, 110) = -1 ECONNREFUSED (Connection refused) > > So it looks like an issue with the listening socket. Ran some more tests on the socket... > > [root at comipa02 ~]# ls -lZ /var/run/slapd-ITMODEV-GOV.socket > srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-ITMODEV-GOV.socket > > So the socket exists but " lsof -U -a -udirsrv" gives me no return...nothing. > > Anybody know what I need to do to fix the socket? Here are a few random ideas: Ensure that nsslapd-ldapifilepath points to the right place in dse.ldif (to your /var/run/slapd-INSTANCE.socket) Ensure that nsslapd-ldapilisten and nsslapd-ldapiautobind are on (also dse.ldif) Remember that to tweak dse.ldif directly dirsrv needs to be shutdown. Try removing the socket and restarting dirsrv Look for SELinux AVCs (though your context looks right): # ausearch -m AVC -ts recent rob From Christopher.Gronde at fincen.gov Fri Nov 13 15:13:26 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Fri, 13 Nov 2015 15:13:26 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5645F3AB.8060100@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> <5633760A.7050000@redhat.com> <56448DA8.4000301@jmips.co.uk> <5644AE5E.2020106@redhat.com> <5644B531.3040507@jmips.co.uk> <5644BB0D.3030209@redhat.com> <2909CC7109523F4BA968E7A201471B771828DA2C@hqexdb01.hqfincen.gov> <5645F3AB.8060100@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771828DB8A@hqexdb01.hqfincen.gov> THAT WORKED!!!! THANKS ROB!! I OWE YOU A BEER! -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Friday, November 13, 2015 9:29 AM To: Gronde, Christopher (Contractor) ; James Masson ; Martin Kosek ; freeipa-users at redhat.com; Jan Cholasta ; David Kupka ; Endi Sukma Dewata Subject: Re: [Freeipa-users] IPA with external CA signed certs Gronde, Christopher (Contractor) wrote: > For those of you that have been helping me...thank you! For all those following along here is the status of my issues. > > I ended up replacing the krbprincipal key and the user certificate in LDAP to match what is on the master and I am no longer getting the invalid credentials error! So thanks for that! > > Unfortunately, krb5kdc still will not start... > > When trying to run: > > ldapsearch -Y EXTERNAL -H > ldapi://%2fvar%2frun%2fslapd-ITMODEV-GOV.socket -b > "cn=ITMODEV.GOV,cn=kerberos,dc=itmodev,dc=gov" krbMKey=* > > I get " ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) " > > So we did a strace on that to see if we could find anything and I found: > > connect(3, {sa_family=AF_LOCAL, > sun_path="/var/run/slapd-ITMODEV-GOV.socket"}, 110) = -1 ECONNREFUSED > (Connection refused) > > So it looks like an issue with the listening socket. Ran some more tests on the socket... > > [root at comipa02 ~]# ls -lZ /var/run/slapd-ITMODEV-GOV.socket > srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 > /var/run/slapd-ITMODEV-GOV.socket > > So the socket exists but " lsof -U -a -udirsrv" gives me no return...nothing. > > Anybody know what I need to do to fix the socket? Here are a few random ideas: Ensure that nsslapd-ldapifilepath points to the right place in dse.ldif (to your /var/run/slapd-INSTANCE.socket) Ensure that nsslapd-ldapilisten and nsslapd-ldapiautobind are on (also dse.ldif) Remember that to tweak dse.ldif directly dirsrv needs to be shutdown. Try removing the socket and restarting dirsrv Look for SELinux AVCs (though your context looks right): # ausearch -m AVC -ts recent rob From APtashnik at cccis.com Sun Nov 15 01:54:48 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Sun, 15 Nov 2015 01:54:48 +0000 Subject: [Freeipa-users] Minimal compatibility with REHL / CentOS 5.5 Message-ID: <428D7943-0DBF-4D8A-BF72-FA6EE4CC2759@cccis.com> Hello IPA team, I?m wondering if there is any compatibility that can be established with legacy RHEL CentOS 5.5 machines. Is there any easy way to setup minimal feature set like central authentication and maybe something else? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens at dieskau.pm Tue Nov 17 02:56:18 2015 From: jens at dieskau.pm (Jens Dieskau) Date: Tue, 17 Nov 2015 03:56:18 +0100 Subject: [Freeipa-users] Cannot add or delete ssh user keys Message-ID: <564A9752.1090500@dieskau.pm> Hello everybody, Since the last version of FreeIPA I cannot add or delete any ssh user keys for synced users. Neither on commandline nor web ui. It works flawless with local created users. But it does not work with users created by winsync. See error message below. If I add the ntUser objectClass manually to a local user, it also doesn't work any more. Maybe this is somehow the origin of the bug? Are there any other logs I could check out? Thanks, Jens ipa -vv user-mod name --sshpubkey="ssh-rsa foobar name at host" ipa: INFO: trying https://ipa.cs.ucc.md/ipa/session/json ipa: INFO: Request: { "id": 0, "method": "ping", "params": [ [], {} ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at CS.UCC.MD", "result": { "messages": [ { "code": 13001, "message": "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.156", "name": "VersionMissing", "type": "warning" } ], "summary": "IPA server version 4.2.3. API version 2.156" }, "version": "4.2.3" } ipa: INFO: Forwarding 'user_mod' to json server 'https://ipa.cs.ucc.md/ipa/session/json' ipa: INFO: Request: { "id": 0, "method": "user_mod", "params": [ [ "name" ], { "all": false, "ipasshpubkey": [ "ssh-rsa foobar name at host" ], "no_members": false, "random": false, "raw": false, "rights": false, "version": "2.156" } ] } ipa: INFO: Response: { "error": { "code": 4203, "message": "Type or value exists: ", "name": "DatabaseError" }, "id": 0, "principal": "admin at CS.UCC.MD", "result": null, "version": "4.2.3" } ipa: ERROR: Type or value exists: From rcritten at redhat.com Mon Nov 16 01:34:23 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 15 Nov 2015 20:34:23 -0500 Subject: [Freeipa-users] Minimal compatibility with REHL / CentOS 5.5 In-Reply-To: <428D7943-0DBF-4D8A-BF72-FA6EE4CC2759@cccis.com> References: <428D7943-0DBF-4D8A-BF72-FA6EE4CC2759@cccis.com> Message-ID: <5649329F.4070901@redhat.com> Andrey Ptashnik wrote: > Hello IPA team, > > I?m wondering if there is any compatibility that can be established with > legacy RHEL CentOS 5.5 machines. Is there any easy way to setup minimal > feature set like central authentication and maybe something else? ipa-client exists there. You can use that. rob From xuezhiy at gmail.com Mon Nov 16 03:00:43 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Mon, 16 Nov 2015 11:00:43 +0800 Subject: [Freeipa-users] FreeIPA user can't login to linux. Message-ID: We integrated the Apache Syncope server with FreeIPA server. So user can self register ID from Apache Syncope then synchronize to FreeIPA. The problems are: *1) User created from Apache Syncope can't login to linux. The user created from FreeIPA web gui works well.* This is the user(syncopex5) information created from Apache Syncope: # syncopex5, users, compat, example.com dn: uid=syncopex5,cn=users,cn=compat,dc=example,dc=com cn: x5syncope objectClass: posixAccount objectClass: top gidNumber: 657600034 gecos: x5syncope uidNumber: 657600034 loginShell: /bin/sh homeDirectory: /home/syncopex5 uid: syncopex5 # syncopex5, users, accounts, example.com dn: uid=syncopex5,cn=users,cn=accounts,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixAccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry cn: x5syncope displayName: x5syncope uid: syncopex5 gecos: x5syncope uidNumber: 657600034 gidNumber: 657600034 loginShell: /bin/sh homeDirectory: /home/syncopex5 sn: syncope givenName: x5 initials: xs # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 *2) The user also can't be deleted from web UI and CLI. It said "syncopex5: user not found".* *The errors log:* [13/Nov/2015:07:27:54 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4130 (rc: 32) [13/Nov/2015:07:27:54 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4131 (rc: 32) [13/Nov/2015:07:27:54 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4221 (rc: 32) [13/Nov/2015:07:27:54 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4222 (rc: 32) [13/Nov/2015:07:27:55 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4353 (rc: 32) [13/Nov/2015:07:27:55 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 4354 (rc: 32) [15/Nov/2015:07:27:53 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 5129 (rc: 32) [15/Nov/2015:07:27:53 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 5130 (rc: 32) [15/Nov/2015:07:27:53 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 5155 (rc: 32) [15/Nov/2015:07:27:53 +0000] DSRetroclPlugin - delete_changerecord: could not delete change record 5156 (rc: 32) [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) *The access log:* [16/Nov/2015:02:52:50 +0000] conn=5512 op=36 UNBIND [16/Nov/2015:02:52:50 +0000] conn=5512 op=36 fd=621 closed - U1 [16/Nov/2015:02:52:59 +0000] conn=5513 fd=621 slot=621 connection from 192.168.10.39 to 192.168.10.39 [16/Nov/2015:02:52:59 +0000] conn=5513 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Nov/2015:02:52:59 +0000] conn=5513 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Nov/2015:02:52:59 +0000] conn=5513 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Nov/2015:02:52:59 +0000] conn=5513 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Nov/2015:02:52:59 +0000] conn=5513 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Nov/2015:02:52:59 +0000] conn=5513 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" [16/Nov/2015:02:52:59 +0000] conn=5513 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [16/Nov/2015:02:52:59 +0000] conn=5513 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=4 SRCH base="cn=users,cn=accounts,dc=example,dc=com" scope=1 filter="(&(objectClass=posixaccount)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))" attrs="telephoneNumber sshpubkeyfp uid title loginShell uidNumber gidNumber sn homeDirectory mail givenName nsAccountLock" [16/Nov/2015:02:52:59 +0000] conn=5513 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=5 SRCH base="uid=admin,cn=users,cn=accounts,dc=example,dc=com" scope=0 filter="(userPassword=*)" attrs="userPassword" [16/Nov/2015:02:52:59 +0000] conn=5513 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=6 SRCH base="uid=admin,cn=users,cn=accounts,dc=example,dc=com" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" [16/Nov/2015:02:52:59 +0000] conn=5513 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=7 SRCH base="uid=admin,cn=users,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" [16/Nov/2015:02:52:59 +0000] conn=5513 op=7 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=8 SRCH base="cn=users,cn=accounts,dc=example,dc=com" scope=2 filter="(&(objectClass=posixaccount)(uid=syncopex5))" attrs="" [16/Nov/2015:02:52:59 +0000] conn=5513 op=8 RESULT err=0 tag=101 nentries=1 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=9 SRCH base="cn=otp,dc=example,dc=com" scope=1 filter="(&(objectClass=ipatoken)(ipatokenOwner=uid=syncopex5,cn=users,cn=accounts,dc=example,dc=com))" attrs="ipatokenNotAfter description ipatokenOwner objectClass ipatokenDisabled ipatokenVendor managedBy ipatokenModel ipatokenNotBefore ipatokenUniqueID ipatokenSerial" [16/Nov/2015:02:52:59 +0000] conn=5513 op=9 RESULT err=0 tag=101 nentries=0 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=10 DEL dn="uid=syncopex5,cn=users,cn=accounts,dc=example,dc=com" [16/Nov/2015:02:52:59 +0000] conn=5513 op=10 RESULT err=32 tag=107 nentries=0 etime=0 [16/Nov/2015:02:52:59 +0000] conn=5513 op=11 UNBIND [16/Nov/2015:02:52:59 +0000] conn=5513 op=11 fd=621 closed - U1 [16/Nov/2015:02:53:10 +0000] conn=13 op=3705 SRCH base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn" [16/Nov/2015:02:53:10 +0000] conn=13 op=3705 RESULT err=32 tag=101 nentries=0 etime=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 16 03:24:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 15 Nov 2015 22:24:16 -0500 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: References: Message-ID: <56494C60.7040709@redhat.com> zhiyong xue wrote: > We integrated the Apache Syncope server with FreeIPA server. So user can > self register ID from Apache Syncope then synchronize to FreeIPA. The > problems are: > *1) User created from Apache Syncope can't login to linux. The user > created from FreeIPA web gui works well.* For login issues see https://fedorahosted.org/sssd/wiki/Troubleshooting This is unlikely to fix things but it will help with later debugging. This likely revolves around how you are creating these accounts. We'll need information on what you're doing. The more details the better. > *2) The user also can't be deleted from web UI and CLI. It said > "syncopex5: user not found".* Again, you probably aren't creating the users correctly. I can only assume that you are creating the users directly via an LDAP add. This is working around the IPA framework which does additional work. Knowing what version of IPA this is would help too. You'll probably also want to read this: http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is in IPA 4.2. rob rob From xuezhiy at gmail.com Mon Nov 16 05:43:19 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Mon, 16 Nov 2015 13:43:19 +0800 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: <56494C60.7040709@redhat.com> References: <56494C60.7040709@redhat.com> Message-ID: I am using IPA 4.1 in CenOS7. And I can login to system after "id syncopex5", maybe it's cache problem. 2015-11-16 11:24 GMT+08:00 Rob Crittenden : > zhiyong xue wrote: > > We integrated the Apache Syncope server with FreeIPA server. So user can > > self register ID from Apache Syncope then synchronize to FreeIPA. The > > problems are: > > *1) User created from Apache Syncope can't login to linux. The user > > created from FreeIPA web gui works well.* > > For login issues see https://fedorahosted.org/sssd/wiki/Troubleshooting > This is unlikely to fix things but it will help with later debugging. > > This likely revolves around how you are creating these accounts. We'll > need information on what you're doing. The more details the better. > > > *2) The user also can't be deleted from web UI and CLI. It said > > "syncopex5: user not found".* > > Again, you probably aren't creating the users correctly. > > I can only assume that you are creating the users directly via an LDAP > add. This is working around the IPA framework which does additional work. > > Knowing what version of IPA this is would help too. > > You'll probably also want to read this: > http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is in > IPA 4.2. > > rob > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Nov 16 09:24:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Nov 2015 10:24:10 +0100 Subject: [Freeipa-users] Minimal compatibility with REHL / CentOS 5.5 In-Reply-To: <5649329F.4070901@redhat.com> References: <428D7943-0DBF-4D8A-BF72-FA6EE4CC2759@cccis.com> <5649329F.4070901@redhat.com> Message-ID: <5649A0BA.4010800@redhat.com> On 11/16/2015 02:34 AM, Rob Crittenden wrote: > Andrey Ptashnik wrote: >> Hello IPA team, >> >> I?m wondering if there is any compatibility that can be established with >> legacy RHEL CentOS 5.5 machines. Is there any easy way to setup minimal >> feature set like central authentication and maybe something else? > > ipa-client exists there. You can use that. > > rob You can even use the login of AD Users via FreeIPA Trust Legacy Client feature. More info here: https://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-legacy.html Martin From tbabej at redhat.com Mon Nov 16 09:49:04 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 16 Nov 2015 10:49:04 +0100 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: References: <56494C60.7040709@redhat.com> Message-ID: <5649A690.2030402@redhat.com> Can you provide a result of a LDAP search run on that entry? As Rob points out, you're probably creating the user in a manner that bypasses the framework. Tomas On 11/16/2015 06:43 AM, zhiyong xue wrote: > I am using IPA 4.1 in CenOS7. And I can login to system after "id > syncopex5", maybe it's cache problem. > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden >: > > zhiyong xue wrote: > > We integrated the Apache Syncope server with FreeIPA server. So user can > > self register ID from Apache Syncope then synchronize to FreeIPA. The > > problems are: > > *1) User created from Apache Syncope can't login to linux. The user > > created from FreeIPA web gui works well.* > > For login issues see https://fedorahosted.org/sssd/wiki/Troubleshooting > This is unlikely to fix things but it will help with later debugging. > > This likely revolves around how you are creating these accounts. We'll > need information on what you're doing. The more details the better. > > > *2) The user also can't be deleted from web UI and CLI. It said > > "syncopex5: user not found".* > > Again, you probably aren't creating the users correctly. > > I can only assume that you are creating the users directly via an LDAP > add. This is working around the IPA framework which does additional > work. > > Knowing what version of IPA this is would help too. > > You'll probably also want to read this: > http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is in > IPA 4.2. > > rob > rob > > > > From APtashnik at cccis.com Mon Nov 16 17:52:57 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 16 Nov 2015 17:52:57 +0000 Subject: [Freeipa-users] Minimal compatibility with REHL / CentOS 5.5 In-Reply-To: <5649A0BA.4010800@redhat.com> References: <428D7943-0DBF-4D8A-BF72-FA6EE4CC2759@cccis.com> <5649329F.4070901@redhat.com> <5649A0BA.4010800@redhat.com> Message-ID: <03E823DC-E7E0-4776-9267-3DE21FBDD944@cccis.com> Thank you, Rob and Martin! I was under impression that that v.5 was not supported at all, because "yum search ipa? did not return any search results in main or EPEL repository. Andrey Ptashnik On 11/16/15, 3:24 AM, "Martin Kosek" wrote: >On 11/16/2015 02:34 AM, Rob Crittenden wrote: >> Andrey Ptashnik wrote: >>> Hello IPA team, >>> >>> I?m wondering if there is any compatibility that can be established with >>> legacy RHEL CentOS 5.5 machines. Is there any easy way to setup minimal >>> feature set like central authentication and maybe something else? >> >> ipa-client exists there. You can use that. >> >> rob > >You can even use the login of AD Users via FreeIPA Trust Legacy Client feature. >More info here: > >https://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf > >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-legacy.html > >Martin From jstormshak at cccis.com Mon Nov 16 20:58:37 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Mon, 16 Nov 2015 20:58:37 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Message-ID: Greetings --- I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Mon Nov 16 22:46:00 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 16 Nov 2015 17:46:00 -0500 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) In-Reply-To: <5644EEAD.9010608@redhat.com> References: <564497EE.9060702@redhat.com> <5644EEAD.9010608@redhat.com> Message-ID: <20151116224559.GA5723@redhat.com> On Thu, Nov 12, 2015 at 08:55:25PM +0100, Martin Kosek wrote: > On 11/12/2015 04:51 PM, Terry John wrote: > > > >I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. > > CCing Nalin and David for the core dump. More below. My initial guess is that it's the same as the one reported in bug #1260871. There's a fix for a problem that might be the cause in 0.77.6 and 0.78.5. If you can try a 0.77.6 build from the COPR system [1], it'll help us figure out if we've correctly identified the cause, or if the problem you're running into is a different one. Thanks, Nalin [1] https://copr.fedoraproject.org/coprs/nalin/certmonger/build/139854/ From xuezhiy at gmail.com Tue Nov 17 02:15:12 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Tue, 17 Nov 2015 10:15:12 +0800 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: <5649A690.2030402@redhat.com> References: <56494C60.7040709@redhat.com> <5649A690.2030402@redhat.com> Message-ID: I query a new user syncopex8, it's same created from Apache Syncope server. *The output of command "ldapsearch -x -h localhost -b dc=exampe,dc=com uid=syncopex8":* # extended LDIF # # LDAPv3 # base with scope subtree # filter: uid=syncopex8 # requesting: ALL # # syncopex8, users, compat, example.com dn: uid=syncopex8,cn=users,cn=compat,dc=example,dc=com cn: x8syncope objectClass: posixAccount objectClass: top gidNumber: 657600044 gecos: x8syncope uidNumber: 657600044 loginShell: /bin/sh homeDirectory: /home/syncopex8 uid: syncopex8 # syncopex8, users, accounts, example.com dn: uid=syncopex8,cn=users,cn=accounts,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixAccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry cn: x8syncope displayName: x8syncope uid: syncopex8 gecos: x8syncope uidNumber: 657600044 gidNumber: 657600044 loginShell: /bin/sh homeDirectory: /home/syncopex8 sn: syncope givenName: x8 initials: xs # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 *The output of command "ldapsearch -x -h localhost -b dc=exampe,dc=com cn=syncopex8":* # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=syncopex8 # requesting: ALL # # syncopex8, groups, compat, example.com dn: cn=syncopex8,cn=groups,cn=compat,dc=example,dc=com gidNumber: 657600044 objectClass: posixGroup objectClass: top cn: syncopex8 # syncopex8, groups, accounts, example.com dn: cn=syncopex8,cn=groups,cn=accounts,dc=example,dc=com objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top cn: syncopex8 gidNumber: 657600044 description: User private group for syncopex8 mepManagedBy: uid=syncopex8,cn=users,cn=accounts,dc=example,dc=com ipaUniqueID: 1c07557c-8cce-11e5-8f72-fa163e630e3d # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 *The output of command "ipa user-showsyncopex8 --raw --all"* dn: uid=syncopex8,cn=users,cn=accounts,dc=example,dc=com uid: syncopex8 givenname: x8 sn: syncope cn: x8syncope initials: xs homedirectory: /home/syncopex8 gecos: x8syncope loginshell: /bin/sh mail: x8 at example.com uidnumber: 657600044 gidnumber: 657600044 nsaccountlock: FALSE has_password: TRUE has_keytab: TRUE displayName: x8syncope ipaUniqueID: 1bffe8b4-8cce-11e5-8f72-fa163e630e3d krbExtraData: AALHiEpWcm9vdC9hZG1pbkBCTVguSUJNLkNPTQA= krbLastPwdChange: 20151117015415Z krbPasswordExpiration: 20151117015415Z krbPrincipalName: syncopex8 at EXAMPLE.COM memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com mepManagedEntry: member=syncopex8,cn=groups,cn=accounts,dc=example,dc=com mepManagedEntry: cn=syncopex8,cn=groups,cn=accounts,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixAccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry *The output of command "ipa group-show syncopex8 --raw --all":* dn: cn=syncopex8,cn=groups,cn=accounts,dc=example,dc=com cn: syncopex8 description: User private group for syncopex8 gidnumber: 657600044 ipaUniqueID: 1c07557c-8cce-11e5-8f72-fa163e630e3d mepManagedBy: uid=syncopex8,cn=users,cn=accounts,dc=example,dc=com objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top 2015-11-16 17:49 GMT+08:00 Tomas Babej : > Can you provide a result of a LDAP search run on that entry? As Rob > points out, you're probably creating the user in a manner that bypasses > the framework. > > Tomas > > On 11/16/2015 06:43 AM, zhiyong xue wrote: > > I am using IPA 4.1 in CenOS7. And I can login to system after "id > > syncopex5", maybe it's cache problem. > > > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden > >: > > > > zhiyong xue wrote: > > > We integrated the Apache Syncope server with FreeIPA server. So > user can > > > self register ID from Apache Syncope then synchronize to FreeIPA. > The > > > problems are: > > > *1) User created from Apache Syncope can't login to linux. The user > > > created from FreeIPA web gui works well.* > > > > For login issues see > https://fedorahosted.org/sssd/wiki/Troubleshooting > > This is unlikely to fix things but it will help with later debugging. > > > > This likely revolves around how you are creating these accounts. > We'll > > need information on what you're doing. The more details the better. > > > > > *2) The user also can't be deleted from web UI and CLI. It said > > > "syncopex5: user not found".* > > > > Again, you probably aren't creating the users correctly. > > > > I can only assume that you are creating the users directly via an > LDAP > > add. This is working around the IPA framework which does additional > > work. > > > > Knowing what version of IPA this is would help too. > > > > You'll probably also want to read this: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is > in > > IPA 4.2. > > > > rob > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 17 08:55:55 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Nov 2015 09:55:55 +0100 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: Message-ID: <20151117085555.GD3768@hendrix.arn.redhat.com> On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: > Greetings --- > I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... > > I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! Not sure about TLS but sudoers should be managed with their ldap config (there's no sssd, hence to sssd sudo integration..) From jens at dieskau.pm Tue Nov 17 08:58:39 2015 From: jens at dieskau.pm (Jens Dieskau) Date: Tue, 17 Nov 2015 09:58:39 +0100 Subject: [Freeipa-users] Cannot add or delete ssh user keys In-Reply-To: <564A9752.1090500@dieskau.pm> References: <564A9752.1090500@dieskau.pm> Message-ID: <564AEC3F.3020602@dieskau.pm> I found the problem and opened a new ticket at https://fedorahosted.org/freeipa/ticket/5456 Am 17.11.2015 um 03:56 schrieb Jens Dieskau: > Hello everybody, > > Since the last version of FreeIPA I cannot add or delete any ssh user > keys for synced users. Neither on commandline nor web ui. > > It works flawless with local created users. But it does not work with > users created by winsync. See error message below. > > If I add the ntUser objectClass manually to a local user, it also > doesn't work any more. Maybe this is somehow the origin of the bug? > Are there any other logs I could check out? > > > Thanks, > Jens > > > ipa -vv user-mod name --sshpubkey="ssh-rsa foobar name at host" > ipa: INFO: trying https://ipa.cs.ucc.md/ipa/session/json > ipa: INFO: Request: { > "id": 0, > "method": "ping", > "params": [ > [], > {} > ] > } > ipa: INFO: Response: { > "error": null, > "id": 0, > "principal": "admin at CS.UCC.MD", > "result": { > "messages": [ > { > "code": 13001, > "message": "API Version number was not sent, forward > compatibility not guaranteed. Assuming server's API version, 2.156", > "name": "VersionMissing", > "type": "warning" > } > ], > "summary": "IPA server version 4.2.3. API version 2.156" > }, > "version": "4.2.3" > } > ipa: INFO: Forwarding 'user_mod' to json server > 'https://ipa.cs.ucc.md/ipa/session/json' > ipa: INFO: Request: { > "id": 0,Since the last version of FreeIPA I cannot add or delete any ssh user keys for synced users. Neither on commandline nor web ui. > "method": "user_mod", > "params": [ > [ > "name" > ], > { > "all": false, > "ipasshpubkey": [ > "ssh-rsa foobar name at host" > ], > "no_members": false, > "random": false, > "raw": false, > "rights": false, > "version": "2.156" > } > ] > } > ipa: INFO: Response: { > "error": { > "code": 4203, > "message": "Type or value exists: ", > "name": "DatabaseError" > }, > "id": 0, > "principal": "admin at CS.UCC.MD", > "result": null, > "version": "4.2.3" > } > ipa: ERROR: Type or value exists: > From Terry.John at completeautomotivesolutions.co.uk Tue Nov 17 10:56:43 2015 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Tue, 17 Nov 2015 10:56:43 +0000 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) In-Reply-To: <20151116224559.GA5723@redhat.com> References: <564497EE.9060702@redhat.com> <5644EEAD.9010608@redhat.com> <20151116224559.GA5723@redhat.com> Message-ID: >On Thu, Nov 12, 2015 at 08:55:25PM +0100, Martin Kosek wrote: >> On 11/12/2015 04:51 PM, Terry John wrote: >> > >> >I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. >> >> CCing Nalin and David for the core dump. More below. >My initial guess is that it's the same as the one reported in bug #1260871. There's a fix for a problem that might be the cause in 0.77.6 and 0.78.5. If you can try a 0.77.6 build from the COPR system >[1], it'll help us figure out if we've correctly identified the cause, or if the problem you're running into is a different one. >Nalin >[1] https://copr.fedoraproject.org/coprs/nalin/certmonger/build/139854/ I'm not sure updating certmonger would help us in this case. The problem was that the CMS service was not running which was a Java version issue. The Java installation in /usr/java/default/bin was version 1.6. Currently certmonger is and everything else is running fine. # yum list installed certmonger Installed Packages certmonger.x86_64 0.77.5-1.el6 @base # service certmonger status certmonger (pid 2288) is running... # ls -l /usr/java/default/bin/java lrwxrwxrwx. 1 root root 22 Nov 13 14:14 /usr/java/default/bin/java -> /etc/alternatives/java # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 46 Nov 13 14:13 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC From jstormshak at cccis.com Tue Nov 17 14:43:26 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 17 Nov 2015 14:43:26 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <20151117085555.GD3768@hendrix.arn.redhat.com> References: <20151117085555.GD3768@hendrix.arn.redhat.com> Message-ID: Thank you for the response. If I may, can you expand more on the sudoers response? More details from my configuration ... The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. uri ldap://ldap-server-name/ sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM bindpw secret_pass bind_timelimit 5 timelimit 15 In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek Sent: Tuesday, November 17, 2015 2:56 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: > Greetings --- > I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... > > I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! Not sure about TLS but sudoers should be managed with their ldap config (there's no sssd, hence to sssd sudo integration..) -- 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 From rcritten at redhat.com Tue Nov 17 15:51:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Nov 2015 10:51:07 -0500 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> Message-ID: <564B4CEB.7040206@redhat.com> Jeffrey Stormshak wrote: > Thank you for the response. If I may, can you expand more on the sudoers response? > > More details from my configuration ... > The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. > > uri ldap://ldap-server-name/ > sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM > bindpw secret_pass > bind_timelimit 5 > timelimit 15 > > In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? It's hard to know what to recommend since you haven't said what isn't working. Your nssswitch.conf should have: sudoers: files ldap You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. You almost certainly want to use TLS here: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes You also need your nisdomainname set to your domain to do group or host-based sudo. You also need to add this to your sssd.conf: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com Stick it after ipa_server in the config file. Use sudo -l to test. rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Tuesday, November 17, 2015 2:56 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: >> Greetings --- >> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... >> >> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! > > Not sure about TLS but sudoers should be managed with their ldap config (there's no sssd, hence to sssd sudo integration..) > > -- > 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 > From jstormshak at cccis.com Tue Nov 17 16:44:20 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 17 Nov 2015 16:44:20 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <564B4CEB.7040206@redhat.com> References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> Message-ID: Thanks Rob! Sorry, I didn't forget to mention what was the message. It basically stated the message listed below. Sorry, user plmoss may not run sudo on client_server Let me try your suggestions and see if that helps lead me down the right path. Once again, thanks for this feedback. Oh how I miss using the "ipa-client" I used on all of my higher Linux versions. Talk about saving time cycles and deployment timeframes. Oh well. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 17, 2015 9:51 AM To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Jeffrey Stormshak wrote: > Thank you for the response. If I may, can you expand more on the sudoers response? > > More details from my configuration ... > The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. > > uri ldap://ldap-server-name/ > sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn > uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM > bindpw secret_pass > bind_timelimit 5 > timelimit 15 > > In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? It's hard to know what to recommend since you haven't said what isn't working. Your nssswitch.conf should have: sudoers: files ldap You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. You almost certainly want to use TLS here: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes You also need your nisdomainname set to your domain to do group or host-based sudo. You also need to add this to your sssd.conf: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com Stick it after ipa_server in the config file. Use sudo -l to test. rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Tuesday, November 17, 2015 2:56 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: >> Greetings --- >> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... >> >> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! > > Not sure about TLS but sudoers should be managed with their ldap > config (there's no sssd, hence to sssd sudo integration..) > > -- > 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 > From jstormshak at cccis.com Tue Nov 17 16:48:53 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 17 Nov 2015 16:48:53 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> Message-ID: I meant "did" forget. Silly typo on my behalf... -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak Sent: Tuesday, November 17, 2015 10:44 AM To: Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Thanks Rob! Sorry, I didn't forget to mention what was the message. It basically stated the message listed below. Sorry, user plmoss may not run sudo on client_server Let me try your suggestions and see if that helps lead me down the right path. Once again, thanks for this feedback. Oh how I miss using the "ipa-client" I used on all of my higher Linux versions. Talk about saving time cycles and deployment timeframes. Oh well. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 17, 2015 9:51 AM To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Jeffrey Stormshak wrote: > Thank you for the response. If I may, can you expand more on the sudoers response? > > More details from my configuration ... > The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. > > uri ldap://ldap-server-name/ > sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn > uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM > bindpw secret_pass > bind_timelimit 5 > timelimit 15 > > In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? It's hard to know what to recommend since you haven't said what isn't working. Your nssswitch.conf should have: sudoers: files ldap You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. You almost certainly want to use TLS here: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes You also need your nisdomainname set to your domain to do group or host-based sudo. You also need to add this to your sssd.conf: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com Stick it after ipa_server in the config file. Use sudo -l to test. rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Tuesday, November 17, 2015 2:56 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: >> Greetings --- >> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... >> >> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! > > Not sure about TLS but sudoers should be managed with their ldap > config (there's no sssd, hence to sssd sudo integration..) > > -- > 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 From Daryl.Fonseca-Holt at umanitoba.ca Tue Nov 17 20:55:48 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Tue, 17 Nov 2015 14:55:48 -0600 Subject: [Freeipa-users] SOLVED Fwd: Re: ipa user-add slows down as more users are added In-Reply-To: <563BDA29.3000603@umanitoba.ca> References: <563BDA29.3000603@umanitoba.ca> Message-ID: <564B9454.3050900@umanitoba.ca> Hi all, Splitting ipausers helped ipa user-add speed a lot. Two other things helped: 1) Setting nsslapd-cachememsize much larger than the size of the id2entry file 2) Increasing the size of the DN cache size, nsslapd-ndn-cache-max-size I've got 60,000+ users now and user-add only takes slightly over three seconds. Because we will continue to add large number of users at the start of the University's fall term and the new userids will be sequential I chose to use a prime number, 211, of ipauser groups and hash the userid. Thus the new ones will spread evenly over the groups and we should end up with less than 1,000 users per group. Thanks again for your help, Daryl -------- Forwarded Message -------- Subject: Re: [Freeipa-users] ipa user-add slows down as more users are added Date: Thu, 5 Nov 2015 16:37:29 -0600 From: Daryl Fonseca-Holt To: Rich Megginson On 11/04/15 17:25, Rich Megginson wrote: > On 11/04/2015 04:07 PM, Rob Crittenden wrote: >> Daryl Fonseca-Holt wrote: >>> Hi All, >>> >>> I am testing migration from NIS with a custom MySQL backend to IPA. In >>> our testing ipa user-add starts out at around 12 seconds per user but >>> slows down as more users are add. By 5000+ users it is taking 90+ >>> seconds. We have 120,000+ users. I'm looking at 155 days to load all >>> the >>> users :( >>> >>> Per some performance tuning documentation I've increased >>> nsslapd-cachememsize to 35,651,584 and am currently getting pretty high >>> hit ratios (see below). > > Use dbmon.sh instead of db_stat - it will give you the entry cache > information as well as a summary of the db cache information (instead > of the quite verbose db_stat output). > Thanks for the tip. I've got some tuning to do. My dbcachefree is negative and the roevicts are high. >>> However, one thread of ns-slapd pegs out core at >>> 100% and I can't get get it to add users any faster. I'm not seeing any >>> I/O or memory swapping. >> The problem is most likely the default IPA users group. As it gets >> humongous adding new members slows it down. > > So could he disable the automember and memberof plugins? Then have > those work offline, after the users are added? > >> >>> Suggestions would be appreciated. Multi-master will probably help but >>> with that many accounts it would take a lot of masters to get additions >>> done to a resonable (45 seconds or less?) time. Is there any guideline >>> for number of users per master? >> IPA is multi-master. All users are on all masters. >> >> If anything I'd expect that running imports on different masters would >> slow things down as changes on multiple masters would need to get merged >> together, particularly the default group. > > Right. > >> >> Certainly bumping up the caches to match what the final expected sizes >> is probably a good idea but I don't see it influencing import speed all >> that much. > > Right. > >> >> One idea I've had is to add the users in batches of 1000. What you'd do >> is create 120 non-POSIX user groups, ipausers1..ipausers120, and add >> them as members of ipausers. >> >> Then for each batch change the default ipausers group with: >> >> $ ipa config-mod --defaultgroup= >> >> This should keep the user-add command fairly peppy and keep the ipausers >> group somewhat in check via the nesting. I'm doing this but with a twist. I have an existing user base so I'm going to use the existing UID to hash to one of the ipauser groups. Will do round-robin for future adds. Being an education institution we get a lot of new accounts each fall. >> >> I imagine that the UI would blow up if you tried to view the ipausers >> group as it tried to dereference 120k users. >> >> You'll probably also want to disable the compat module for the import. >> I'll give this a try too. >> I assume you've already done some amount of testing with a smaller batch >> of users to ensure they migrate ok, passwords work, etc? >> >> rob >> > Thanks to both of you. It will be a while before I can report the fruits of this exercise. I'm reluctant to give up the 5000+ that I've already added so I'm deleting them from ipauser and adding them to the appropriate ipauser. Meantime I've got a bunch of other scripts to write for some of the custom stuff we did with PAM and the old MySQL backend. Regards, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Wed Nov 18 02:36:41 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 17 Nov 2015 21:36:41 -0500 Subject: [Freeipa-users] "ASN.1 structure is missing a required field" - what is missing? Message-ID: I'm putting together a java kerberos client and am having an issue getting a SGT form IPA. I get a TGT without issue, but when I submit the TGS-REQ I get the following errors in the ipa log: Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0, for HTTP/ipa.rhelent.lan at RHELENT.LAN, ASN.1 structure is missing a required field Here's the TGS request: Kerberos tgs-req pvno: 5 msg-type: krb-tgs-req (12) padata: 1 item PA-DATA PA-TGS-REQ padata-type: kRB5-PADATA-TGS-REQ (1) padata-value: 6e8201f8308201f4a003020105a10302010ea20703050000... ap-req pvno: 5 msg-type: krb-ap-req (14) Padding: 0 ap-options: 00000000 0... .... = reserved: False .0.. .... = use-session-key: False ..0. .... = mutual-required: False ticket tkt-vno: 5 realm: RHELENT.LAN sname name-type: kRB5-NT-PRINCIPAL (1) name-string: 2 items KerberosString: krbtgt KerberosString: RHELENT.LAN enc-part etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) kvno: 1 cipher: 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11... authenticator etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) kvno: 255 cipher: f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74... req-body Padding: 0 kdc-options: 00000000 0... .... = reserved: False .0.. .... = forwardable: False ..0. .... = forwarded: False ...0 .... = proxiable: False .... 0... = proxy: False .... .0.. = allow-postdate: False .... ..0. = postdated: False .... ...0 = unused7: False 0... .... = renewable: False .0.. .... = unused9: False ..0. .... = unused10: False ...0 .... = opt-hardware-auth: False .... ..0. = request-anonymous: False .... ...0 = canonicalize: False 0... .... = constrained-delegation: False ..0. .... = disable-transited-check: False ...0 .... = renewable-ok: False .... 0... = enc-tkt-in-skey: False .... ..0. = renew: False .... ...0 = validate: False cname name-type: kRB5-NT-PRINCIPAL (1) name-string: 2 items KerberosString: HTTP KerberosString: s4u.rhelent.lan realm: RHELENT.LAN sname name-type: kRB5-NT-PRINCIPAL (1) name-string: 2 items KerberosString: HTTP KerberosString: ipa.rhelent.lan from: 2015-11-18 02:17:44 (UTC) till: 2015-11-18 10:17:44 (UTC) nonce: 604310537 etype: 1 item ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) Is there a field missing? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com From ftweedal at redhat.com Wed Nov 18 06:01:18 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 18 Nov 2015 16:01:18 +1000 Subject: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved) In-Reply-To: <5645C2C0.7090806@redhat.com> References: <5645C2C0.7090806@redhat.com> Message-ID: <20151118060117.GF5336@dhcp-40-8.bne.redhat.com> On Fri, Nov 13, 2015 at 12:00:16PM +0100, Martin Kosek wrote: > On 11/13/2015 11:14 AM, Terry John wrote: > >>On 11/12/2015 04:51 PM, Terry John wrote: > >>>I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful. > > > >>CCing Nalin and David for the core dump. More below. > > > >>On 11/12/2015 02:17 PM, Terry John wrote: > >>>>I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue. > >>>>My current version of ipa-server is 3.0.0-47 Certmonger crashes with > >>>>a segmentation fault at boot time and crashes every time I try to restart it when ipa is running. > >> > > > > > >>>>># ipa cert-status > >>>>>Request id: 20140417164153 > >>>>>ipa: ERROR: Certificate operation cannot be completed: Unable to > >>>>>communicate with CMS (Service Unavailable) # service certmonger > >>>>>status certmonger (pid 3030) is running... > >>> > >>>>It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug. > >>>Yes ipa cert-show 1 does show the same thing # ipa cert-show 1 > >>>ipa: ERROR: Certificate operation cannot be completed: Unable to > >>>communicate with CMS (Service Unavailable) > >>> > >>>>Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong. > >>>I'm pretty certain the dogtag service is not running > > > >Then you have your lucky winner! :-) > > > >>>>Some pointers to logs are for example here: > >>>>http://www.freeipa.org/page/Troubleshooting#Server_Installation > >> > >>>/var/log/pki-ca/catalina.out contains the lines at boot time: > > > > > >>>SEVERE: Error deploying web application directory ca > >>>java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> lassLoader.java:2334).... lots of traceback > >>> > >>>/var/log/pki-ca/system is empty > >>>/var/log/pki-ca/debug has nothing new for 2 days > > > >>CCing Fraser. This is a wild guess, but maybe you updated your java to java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS: > > > >>https://bugzilla.redhat.com/show_bug.cgi?id=1262516 > > > >>java would need to be switched with "alternate" to pre-1.8.0 version if this is the case. > > > >The java version was the problem. > > Good! Fraser, can we improve anything in pki-core, so that wrong java > version issue like this one does not occur? IIRC, pki-core in RHEL-6.x was > updated to somehow deal with java 1.8.0 (conflict), not sure if lower > versions are also covered. > AFAICT there is no such protection. It seems to be more of an unspoken "don't do that". I guess the right approach when an unsupported alternative is selected is to explicitly use a supported one. I'm not sure what's involved in making that change or whether it is worth the effort. Adding pki-devel for comment from those with packaging experience. Cheers, Fraser > >Luckily I have a java expert to hand and explained that major.minor version 51.0 corresponds to java 7 > >http://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers > >When I did > ># ps ax | grep java I got" > >1460 ? Sl 1:21 /usr/java/default/bin/java -Djavax.sql.Da....... > ># /usr/java/default/bin/java -version > >java version "1.6.0_31" > >Java(TM) SE Runtime Environment (build 1.6.0_31-b04) > >Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) > > > >I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the /usr/java/default/bin is all from java-1.6.0-openjdk > > > >I have renamed /usr/java/default/bin/java to javaold and done > ># ln -s /usr/bin/java /usr/java/default/bin/java > ># /usr/java/default/bin/java -version > >java version "1.7.0_91" > >OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00) > >OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode) > > This may work, but looks a bit hacky. I think the right way is to use > "alternate" program I mentioned earlier to let you choose the right version > of the java executable and/or libraries. > > >After a reboot FreeIPA works properly which is great but I'm wondering if there is a better fix though since all the other executables in are from the 1.6 version. I can't find a corresponding location for 1.7 executables. > > The "alternate" approach should "just work". I am glad you made the instance > working again! > > > > >Thanks very much > > > > > >The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > > >V:0CF72C13B2AC > > > > > From prashant at apigee.com Wed Nov 18 06:24:54 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 18 Nov 2015 11:54:54 +0530 Subject: [Freeipa-users] Restricting access to unencrypted LDAP connections Message-ID: Hi, We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients configured to talk to them thru pam-nss-ldapd (no sssd). I want to ensure that these clients only talk to freeipa's LDAP server either via ldaps or ldap+starttls. Plain ldap should not be allowed. I can always switch to ldaps only and close the tcp/389 port on the firewall. But is there a way to achieve this using tcp/389 port.? Any suggestions appreciated. Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed Nov 18 07:56:33 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 18 Nov 2015 08:56:33 +0100 Subject: [Freeipa-users] Restricting access to unencrypted LDAP connections In-Reply-To: References: Message-ID: <564C2F31.60809@redhat.com> you could set minssf: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html#requiring-secure-connections On 11/18/2015 07:24 AM, Prashant Bapat wrote: > Hi, > > We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients > configured to talk to them thru pam-nss-ldapd (no sssd). I want to > ensure that these clients only talk to freeipa's LDAP server either > via ldaps or ldap+starttls. Plain ldap should not be allowed. > > I can always switch to ldaps only and close the tcp/389 port on the > firewall. But is there a way to achieve this using tcp/389 port.? > > Any suggestions appreciated. > > Thanks. > --Prashant > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Wed Nov 18 09:23:24 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 18 Nov 2015 14:53:24 +0530 Subject: [Freeipa-users] Restricting access to unencrypted LDAP connections In-Reply-To: <564C2F31.60809@redhat.com> References: <564C2F31.60809@redhat.com> Message-ID: Exactly what I was looking for! Thank you!! On 18 November 2015 at 13:26, Ludwig Krispenz wrote: > you could set minssf: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html#requiring-secure-connections > > > On 11/18/2015 07:24 AM, Prashant Bapat wrote: > > Hi, > > We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients > configured to talk to them thru pam-nss-ldapd (no sssd). I want to ensure > that these clients only talk to freeipa's LDAP server either via ldaps or > ldap+starttls. Plain ldap should not be allowed. > > I can always switch to ldaps only and close the tcp/389 port on the > firewall. But is there a way to achieve this using tcp/389 port.? > > Any suggestions appreciated. > > Thanks. > --Prashant > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdomineaux at gmail.com Wed Nov 18 10:46:40 2015 From: pdomineaux at gmail.com (Domineaux Philippe) Date: Wed, 18 Nov 2015 11:46:40 +0100 Subject: [Freeipa-users] Active Directory Integration and limitations Message-ID: Here is my environment : 1 Windows Domain Windows workstations Windows servers Multiple linux domains Linux workstations Linux servers Here is my goal : All users are centralized in the Active Directory. Users will authenticate on linux workstations with their AD accounts ( using POSIX attributes). Linux workstations must have access to NFS shares on Linux servers. What are the limitations ? Windows users equals ipa users in term of services ? Do I have to configure kerberos to also join directly the Windows Kerberos Realm, or will IPA do the job to ask Windows server ? in etc/krb5.conf : includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = IPA.ORG dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} canonicalize = yes allow_weak_crypto = true [realms] IPA.ORG = { pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@ $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ auth_to_local = DEFAULT } ### IS THIS NECESSARY WINDOMAIN.LOCAL = { kdc = srvadipa.windomain.local admin_server = srvadipa.windomain.local } [domain_realm] .cosmo.org = COSMO.ORG cosmo.org = COSMO.ORG ### IS THIS NECESSARY .windomain.local = WINDOMAIN.LOCAL windomain.local = WINDOMAIN.LOCAL Is the bug in libnfsidmap still active and prevents Windows users to access to NFS4 krb5 secured shared folder ? I currently have bug here: https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From holosian at gmail.com Wed Nov 18 14:32:37 2015 From: holosian at gmail.com (Unknown) Date: Wed, 18 Nov 2015 15:32:37 +0100 Subject: [Freeipa-users] FreeIPA Internal Server Error Message-ID: <1447857157.3197.13.camel@gmail.com> I'm new here so first of all want to say hello to everyone. I'm implementing FreeIPA in our environment. Everything was fine till i figure out listing of one domain stops working. When im trying to list zone via web panel i'm getting "Internal Server Error". It is happening only for default one zone/domain which is used by kerberos too. Here are http error logs: [Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The timeout specified has expired: [client 172.16.0.117:48072] mod_wsgi (pid=11045): Unable to get bucket brigade for request., referer: https: //freeipa01.domain.local/ipa/ui/ [Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR: non- public: IOError: request data read error [Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback (most recent call last): [Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929]???File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 339, in wsgi_execute [Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929]?????data = read_input(environ) [Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929]???File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 187, in read_input [Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929]?????return environ['wsgi.input'].read(length) [Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError: request data read error [Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO: [jsonserver_session] admin at DOMAIN.LOCAL: None: IOError [Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote 172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote 172.16.0.117:164] IOError: failed to write data I realize that it stops working after i try to add Ubuntu instance but Ubuntu client is not work properly. What is strange when im using command client i don't have problem to list it. Regards Holo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Wed Nov 18 07:23:07 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 18 Nov 2015 08:23:07 +0100 Subject: [Freeipa-users] service account for ovirt Message-ID: Hello all, I've read a lot regarding service accounts on this mailinglist in the past. But it's rather unclear to me what is the current preffered method to create a service account for a service running on a different machine. In this case it would be a service account for ovirt so that freeipa users can authenticate in the ovirt portal using their freeipa credentials. I could ofcourse create an account and then apply a ldf to set its password expiration to the next millennium to make sure the password does not expire. Anybody who has a good suggestion on how to deal with this ? Cheers Rob Verduijn From mkosek at redhat.com Wed Nov 18 14:51:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Nov 2015 15:51:50 +0100 Subject: [Freeipa-users] service account for ovirt In-Reply-To: References: Message-ID: <564C9086.901@redhat.com> On 11/18/2015 08:23 AM, Rob Verduijn wrote: > Hello all, > > I've read a lot regarding service accounts on this mailinglist in the past. > But it's rather unclear to me what is the current preffered method to > create a service account for a service running on a different machine. > > In this case it would be a service account for ovirt so that freeipa > users can authenticate in the ovirt portal using their freeipa > credentials. It sounds like that you do not want system user account, but you are OK with service account so that you can get a keytab for your oVirt instance. In that case, simple $ ipa service-add HTTP/frontend.ovirt.test and $ ipa-getkeytab ... should be enough, right? Maybe I just do not understand the use case. > I could ofcourse create an account and then apply a ldf to set its > password expiration to the next millennium to make sure the password > does not expire. > > Anybody who has a good suggestion on how to deal with this ? > > Cheers > Rob Verduijn > From tusharsharma1307 at gmail.com Wed Nov 18 10:28:55 2015 From: tusharsharma1307 at gmail.com (Tushar Sharma) Date: Wed, 18 Nov 2015 15:58:55 +0530 Subject: [Freeipa-users] General guidance Message-ID: Sir/Mam Greeting for the day. I am planing to use freeipa for identity access management for our office network. Currently we are not using any identity or access management software for our users and servers. We have around 200 systems (approx. 120 linux , 70 windows and 5 mac systems.) I have a firewall which supports users from ldap and all users are bound to authenticate against it for Internet access. I need i centralized solution for managing my users and servers. Can you help me in designing a architecture for our network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcoates at liquidweb.com Wed Nov 18 15:35:07 2015 From: bcoates at liquidweb.com (Branden Coates) Date: Wed, 18 Nov 2015 10:35:07 -0500 Subject: [Freeipa-users] Sudo Rules Help (SOLVED) In-Reply-To: <56450B34.4070905@liquidweb.com> References: <56434F97.40405@liquidweb.com> <56445D12.6010203@redhat.com> <56450B34.4070905@liquidweb.com> Message-ID: <564C9AAB.8010908@liquidweb.com> I was able to track down the issues with Cent 5 and the sudo rules. I do not fully understand why, but I assume it has to do with being able to determine the hostname from the fqdn. I ended up having to add the following line to the /etc/sysctl.conf file: nkernel.domainname = Our domain for freeipa is actually a subdomain so possibly this may have had something to do with needing this setting? After adding that line and running a "sysctl -p" sudo was able to identify the servers hostname within the host groups assigned on the sudo rule. At this point everything related to sudo I was having issues with is sorted out. Thanks for pointing me in the right direction to sort the problem out. It looks like in both instances it was just user error and overlooking a few details. On 11/12/2015 04:57 PM, Branden Coates wrote: > Thank you for the welcome! > > So in the process of pulling the output of the log files with the most > recent attempts on cent6 I sorted out the issues with cent6, though > cent5 is still problematic. I added debug_level = 6 to sudo and the > domain in the sssd.conf. Originally I only had this for sudo so I was > missing part of the puzzle. I also removed the lines as suggested from > the sssd.conf since they are un-necessary. I suspect that may have > been something that was a hold over from the migration process between > an old d389 system using ldap.conf and freeipa. > > While I was cleansing the domain logs I could see all the ldap_ > directives detected and the defaults if not defined in sssd.conf. Our > setup does not allow anonymous access so a bind user is required to > pull group info. I added the lines below knowing now that the binddn > directive is invalid: > > ldap_default_bind_dn = > ldap_default_authtok = > > > to the sssd.conf for cent6, reloaded sssd and cleared its cache with > sss_cache -E and attempted to sudo and it worked! > > After sorting that out I moved on to working with cent5, also adding > the two lines above to its sssd.conf. I can now see in the logs that > it finds the users groups and can match that up in the sudo rules but > it is not finding the host in the host groups to match on the sudo > rules. I am attaching the logs from cent5 to show the issue related > here. The host I am testing on is a member of the host group called > "sysops". You can see in the attached sudo_debug that it does find the > sysops sudo rule, and also sees the host group called sysops assigned > to the sudo rule, but it does not find the host within the group. Note > that it prompts for a password, however the sudo rule does have the > option !authenticate on the sysops sudo rule, so once it can find the > host it should no longer prompt for a password. > > I appreciate your taking the time to give insight on this issue. I > have been fighting with this for a few weeks now. > > On 11/12/2015 04:34 AM, Pavel B?ezina wrote: >> On 11/11/2015 03:24 PM, Branden Coates wrote: >>> I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) >>> that I >>> would greatly appreciate some help with. The core of the issue is that >>> sudo rules fail to work when using ldap instead of ipa when you assign >>> user groups and host groups to the sudo rule in place of explicitly >>> adding users and hosts to the sudo rule. The reason for needing to use >>> ldap over ipa is due to the organization requiring 2fa for all users >>> via >>> OTP tokens. We have a mix of cent 5 to 7 systems, not all can be >>> immediately upgraded, so with cent 5 and 6 nodes ldap must be used >>> instead of ipa to support 2fa. >>> Explicitly assigning users and hosts to sudo rules is also >>> unmanageable, >>> the organization has hundreds of employees and multiple thousands of >>> servers. Utilizing the host and user groups is a must. >>> >>> On cent 7 the default sssd.conf generated by FreeIPA works, 2fa >>> works by >>> default and the sssd.conf is using the ipa directives as well to parse >>> user and host groups on sudo rules. Everything here works as expected. >>> >>> In cent 6 to allow 2fa to work the conf has to be updated to use ldap >>> instead of ipa. In the process this seems to break the ability to >>> search >>> user and host groups on sudo rules. Users and hosts explicitly defined >>> for the sudo rules still work so the clients can see the rules, they >>> just do not seem to want to look within the groups that may be assigned >>> to the rules. I moved the original sssd.conf created by FreeIPA using >>> the ipa directives and sudo works as expected, but 2fa is not possible >>> like this. >>> >>> Cent 5 is entirely incapable of using the sudo rules with user and host >>> groups since sudo lacks sssd support in cent 5 and depends on >>> /etc/ldap.conf to work. However like cent 6, users and hosts explicitly >>> defined for the sudo rules still work, so I presume fixing the sudo >>> rules with cent 6 on ldap would fix them here as well. >>> >>> Can anyone else confirm this behavior, and if so can anyone suggest any >>> possible fixes or workarounds? I have attached the modified Cent6 and >>> Cent 5 configs for sssd and ldap inline below(first time mailing, if >>> inline is not ok please let me know what is preferable for future >> >> Hi, >> welcome to the list! I personally prefer receiving it as an >> attachment, since it is more convenient for me to organize and read. >> >>> reference). Currently testing using the following versions: >>> CentOS Linux release 7.1.1503 (Core) >>> CentOS release 6.7 (Final) >>> CentOS release 5.11 (Final) >>> >>> Cent 6 /etc/sssd/sssd.conf: >>> >>> #SSSD client configuration file. >>> [domain/domain] >>> id_provider = ldap >>> auth_provider = ldap >>> chpass_provider = ldap >>> autofs_provider = ldap >>> sudo_provider = ldap >> >>> binddn = >>> bindpw = >>> scope = sub >>> sudoers_base = ou=SUDOers,dc=,dc=com >>> tls_cacertfile = /etc/ipa/ca.crt >>> tls_checkpeer = yes >>> tls_reqcert = demand >>> ssl = start_tls >> >> ^ these are not sssd options thus it should not be in sssd.conf >> >>> >>> ldap_schema = rfc2307bis >>> ldap_uri = _srv_,ldap://.:389 >>> ldap_search_base = dc=,dc=com >>> ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com >>> ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com >>> ldap_sudo_search_base = ou=SUDOers,dc=,dc=com >>> >>> enumerate = True >>> cache_credentials = True >>> >>> ldap_tls_cacertdir = /etc/ipa/ >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> ldap_tls_reqcert = demand >>> ldap_id_use_start_tls = True >>> >>> krb5_realm = >> >> I do not see anything wrong here at first sight. Can you send also >> sssd_sudo.log and sssd_$domain.log please? >> >>> >>> [sssd] >>> services = nss, sudo, pam, ssh, autofs >>> config_file_version = 2 >>> domains = domain >>> >>> [nss] >>> homedir_substring = /home >>> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd >>> >>> [pam] >>> >>> [sudo] >>> >>> [autofs] >>> >>> [ssh] >>> >>> [pac] >>> >>> [ifp] >>> >>> >>> Cent 5 /etc/sssd/sssd.conf: >>> >>> #SSSD client configuration file. >>> [domain/domain] >>> id_provider = ldap >>> auth_provider = ldap >>> chpass_provider = ldap >>> autofs_provider = ldap >>> >>> ldap_schema = rfc2307bis >>> ldap_uri = _srv_,ldap://.:389 >>> ldap_search_base = dc=,dc=com >>> ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com >>> ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com >>> >>> enumerate = True >>> cache_credentials = True >>> >>> ldap_tls_cacertdir = /etc/ipa/ >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> ldap_tls_reqcert = demand >>> ldap_id_use_start_tls = True >>> >>> krb5_realm = >>> >>> [sssd] >>> services = nss, pam >>> config_file_version = 2 >>> domains = domain >>> >>> [nss] >>> homedir_substring = /home >>> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd >>> >>> [pam] >>> >>> >>> Cent 5 /etc/ldap.conf: >>> >>> #LDAP client configuration file. >>> uri ldap://.:389 >>> base dc=,dc=com >>> ldap_version 3 >>> >>> tls_cacertfile /etc/ipa/ca.crt >>> tls_checkpeer yes >>> ssl start_tls >>> >>> binddn >>> bindpw >>> timelimit 5 >>> bind_timelimit 15 >>> >>> sudoers_base ou=SUDOers,dc=,dc=com >>> >>> >>> Thank you >>> Brande >>> >>> >> > -- --------------------------------- Branden Coates Ops Team Liquid Web, Inc. support at liquidweb.com 1-800-580-4985 Toll Free 1-517-322-0434 International --------------------------------- From christopher.lamb at ch.ibm.com Wed Nov 18 15:34:39 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Wed, 18 Nov 2015 16:34:39 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 Message-ID: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to 7.1) The ipa-client is installed, making this server an ipa host. > getent passwd xxxx is successful for ipa users. -->OK However I cannot log on to the host with ipa users (direct or ssh). -->NOT OK When logged on as root (local user), I can ?su -? to my ipa user. -->OK "> systemctl status sssd" and "> kinit" both show: ?Invalid UID in persistent keyring name while getting default cache.? Having googled with this error, I saw some indications that it could be related to the kernel. https://bugzilla.redhat.com/show_bug.cgi?id=1017683 https://bugzilla.redhat.com/show_bug.cgi?id=1029110 For a fresh OEL install, the default kernel is the uek version. "Aha" I thought, let?s change back to the standard RHEL kernel. After a reboot with the RHEL kernel, I was still not able to log in with my ipa user. I then logged on as root, and changed to my ipa user via su. > klist -l produced: KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) I therefore deleted the key: > kdestroy -A Then I stopped the sssd service, and cleared the cache in /var/lib/sss/db/, then restarted sssd After that I was now able to log on with my ipa user (both direct and via ssh). However I cannot get any other ipa users to logon to this host! --> NOT OK The same users can successfully logon to other ipa hosts in the same domain. My ipa user was the one used to enroll the host. Any ideas? sssd version = 1.12.2 58.el7_1.18 ipa-client version = 4.1.0 18.0.1.el7_1.4 kernels: Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-98.5.2.el7uek.x86_64 Oracle Linux Server, with Linux 3.10.0-229.20.1.el7.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Wed Nov 18 15:27:11 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 18 Nov 2015 16:27:11 +0100 Subject: [Freeipa-users] service account for ovirt In-Reply-To: <564C9086.901@redhat.com> References: <564C9086.901@redhat.com> Message-ID: 2015-11-18 15:51 GMT+01:00 Martin Kosek : > On 11/18/2015 08:23 AM, Rob Verduijn wrote: >> Hello all, >> >> I've read a lot regarding service accounts on this mailinglist in the past. >> But it's rather unclear to me what is the current preffered method to >> create a service account for a service running on a different machine. >> >> In this case it would be a service account for ovirt so that freeipa >> users can authenticate in the ovirt portal using their freeipa >> credentials. > > It sounds like that you do not want system user account, but you are OK with > service account so that you can get a keytab for your oVirt instance. In that > case, simple > > $ ipa service-add HTTP/frontend.ovirt.test > and > $ ipa-getkeytab ... > should be enough, right? > > Maybe I just do not understand the use case. > >> I could ofcourse create an account and then apply a ldf to set its >> password expiration to the next millennium to make sure the password >> does not expire. >> >> Anybody who has a good suggestion on how to deal with this ? >> >> Cheers >> Rob Verduijn >> > Hello, I think some more context should clear this up a bit. according to the rhev administrator guide: (ovirt referes to rhev manuals a lot) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html It talks about two options as a single sign on solution. On have the single sign on work for the portal, but then it won't work for the vm's. ( something about not being able to pass a password since the portal won't have one to pass ) Or have the single sign on work for the vm's but than you have to sign in to the portal so it can pass on your credentials to the vm's. I guess there is some interesting technical challenge to deal with to merge those two cases. The first option requires privileges to browse the freeipa directory to look for user accounts. I do not know if that can be solved with something as simple as a keytab and a pricipal. My current working solution is an account with a very long password experation time in the freeipa directory ( a random 32 character/number password is being used for this ) However something tells me that there is a more elegant solution. And I was wondering if anyone knows one. Cheers Rob Verduijn From alan.l.sparks at hpe.com Wed Nov 18 16:47:50 2015 From: alan.l.sparks at hpe.com (Sparks, Alan) Date: Wed, 18 Nov 2015 16:47:50 +0000 Subject: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups Message-ID: <7A7F90629CCF9D488E23F893AF37FEF91FD5BCA2@G9W0717.americas.hpqcorp.net> I still can't find the problem after a lot of searching, can someone give me a little advice? Assembling a POC of FreeIPA 4.1.0 server (stock CentOS-7 packages) and a CentOS 6.7 server with their stock 3.0.0 packages. Sudo version on the client is sudo-1.8.6p3. Have created a general sudo rule on the IPA server to grant access to a host group. However it doesn't allow access, just a "sparksa is not allowed to run sudo on als-centos0002". If I change the rule to not use host groups, and explicitly set the hosts, it works OK. Have checked the stuff I've seen in general search, like the nisdomainname, values are set and look plausible. The sudo debug logs seem to indicate vaguely that it can't match the netgroup: Nov 18 16:07:37 sudo[15713] username=sparksa Nov 18 16:07:37 sudo[15713] domainname=(null) Nov 18 16:07:37 sudo[15713] Received 1 rule(s) Nov 18 16:07:37 sudo[15713] sssd/ldap sudoHost '+opsauto' ... not Nov 18 16:07:37 sudo[15713] Sorting the remaining entries using the sudoOrder attribute Nov 18 16:07:37 sudo[15713] searching SSSD/LDAP for sudoers entries Nov 18 16:07:37 sudo[15713] Done with LDAP searches Nov 18 16:07:37 sudo[15713] keep HOSTNAME=als-centos0002.dakar.useast.hpcloud.net: YES Nov 18 16:07:37 sudo[15713] sudo_putenv: HOSTNAME=als-centos0002.dakar.useast.hpcloud.net The setup of the client used the normal 'ipa-client-install' script. From questions asked before, some salient debugging info: [root at als-centos0002 sys-ops]# nisdomainname dakar.useast.hpcloud.net [root at als-centos0002 sys-ops]# hostname als-centos0002.dakar.useast.hpcloud.net [root at als-centos0002 sys-ops]# getent netgroup opsauto opsauto (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal) (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal) Does anyone have any advice on what additional debug I should look at, just not sure what I'm missing. Thanks in advance. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 18 16:55:00 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Nov 2015 11:55:00 -0500 Subject: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups In-Reply-To: <7A7F90629CCF9D488E23F893AF37FEF91FD5BCA2@G9W0717.americas.hpqcorp.net> References: <7A7F90629CCF9D488E23F893AF37FEF91FD5BCA2@G9W0717.americas.hpqcorp.net> Message-ID: <564CAD64.8080608@redhat.com> Sparks, Alan wrote: > I still can?t find the problem after a lot of searching, can someone > give me a little advice? Assembling a POC of FreeIPA 4.1.0 server > (stock CentOS-7 packages) and a CentOS 6.7 server with their stock 3.0.0 > packages. Sudo version on the client is sudo-1.8.6p3. > > > > Have created a general sudo rule on the IPA server to grant access to a > host group. However it doesn?t allow access, just a ?sparksa is not > allowed to run sudo on als-centos0002?. If I change the rule to not > use host groups, and explicitly set the hosts, it works OK. > > > > Have checked the stuff I?ve seen in general search, like the > nisdomainname, values are set and look plausible. The sudo debug logs > seem to indicate vaguely that it can?t match the netgroup: > > > > Nov 18 16:07:37 sudo[15713] username=sparksa > > Nov 18 16:07:37 sudo[15713] domainname=(null) > > Nov 18 16:07:37 sudo[15713] Received 1 rule(s) > > Nov 18 16:07:37 sudo[15713] sssd/ldap sudoHost '+opsauto' ... not > > Nov 18 16:07:37 sudo[15713] Sorting the remaining entries using the > sudoOrder attribute > > Nov 18 16:07:37 sudo[15713] searching SSSD/LDAP for sudoers entries > > Nov 18 16:07:37 sudo[15713] Done with LDAP searches > > Nov 18 16:07:37 sudo[15713] keep > HOSTNAME=als-centos0002.dakar.useast.hpcloud.net: YES > > Nov 18 16:07:37 sudo[15713] sudo_putenv: > HOSTNAME=als-centos0002.dakar.useast.hpcloud.net > > > > The setup of the client used the normal ?ipa-client-install? script. > From questions asked before, some salient debugging info: > > > > [root at als-centos0002 sys-ops]# nisdomainname > > dakar.useast.hpcloud.net > > [root at als-centos0002 sys-ops]# hostname > > als-centos0002.dakar.useast.hpcloud.net > > [root at als-centos0002 sys-ops]# getent netgroup opsauto > > opsauto > (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal) > (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal) > > > > Does anyone have any advice on what additional debug I should look at, > just not sure what I?m missing. Thanks in advance. Your NIS domain name doesn't match. dakar.useast.hpcloud.net != eucalyptus.internal rob From alan.l.sparks at hpe.com Wed Nov 18 17:19:23 2015 From: alan.l.sparks at hpe.com (Sparks, Alan) Date: Wed, 18 Nov 2015 17:19:23 +0000 Subject: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups In-Reply-To: <564CAD64.8080608@redhat.com> References: <7A7F90629CCF9D488E23F893AF37FEF91FD5BCA2@G9W0717.americas.hpqcorp.net> <564CAD64.8080608@redhat.com> Message-ID: <7A7F90629CCF9D488E23F893AF37FEF91FD5CCD9@G9W0717.americas.hpqcorp.net> >> [root at als-centos0002 sys-ops]# nisdomainname >> dakar.useast.hpcloud.net >> >> [root at als-centos0002 sys-ops]# getent netgroup opsauto >> opsauto >> (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal) >> (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal) > >Your NIS domain name doesn't match. dakar.useast.hpcloud.net != eucalyptus.internal >rob Thanks for that. I must be misunderstanding the purpose of the --domain option. -Alan From jhrozek at redhat.com Wed Nov 18 18:28:27 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 18 Nov 2015 19:28:27 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> Message-ID: <20151118182827.GL2986@hendrix> On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to 7.1) > The ipa-client is installed, making this server an ipa host. > > > > > getent passwd xxxx > > is successful for ipa users. -->OK > > However I cannot log on to the host with ipa users (direct or ssh). -->NOT > > OK > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > "> systemctl status sssd" and "> kinit" > > both show: > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > Having googled with this error, I saw some indications that it could be > > related to the kernel. > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > thought, let?s change back to the standard RHEL kernel. > > After a reboot with the RHEL kernel, I was still not able to log in with my > > ipa user. > > > > I then logged on as root, and changed to my ipa user via su. > > > klist -l > > produced: > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) I'm surprised you had any ccache at all, because login as root bypasses PAM. But in general, if you login with sssd and the cache is expired a long time ago (1970), that means sssd logged you in offline and the ccache is a placeholder for when sssd switches to online mode. > > > > I therefore deleted the key: > > > kdestroy -A > > Then I stopped the sssd service, and cleared the cache in /var/lib/sss/db/, > > then restarted sssd > > > > After that I was now able to log on with my ipa user (both direct and via > > ssh). > > > > However I cannot get any other ipa users to logon to this host! --> NOT OK > > The same users can successfully logon to other ipa hosts in the same > > domain. > > > > My ipa user was the one used to enroll the host. > > > > Any ideas? Not without logs, see: https://fedorahosted.org/sssd/wiki/Troubleshooting From rcritten at redhat.com Wed Nov 18 18:49:09 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Nov 2015 13:49:09 -0500 Subject: [Freeipa-users] FreeIPA Internal Server Error In-Reply-To: <1447857157.3197.13.camel@gmail.com> References: <1447857157.3197.13.camel@gmail.com> Message-ID: <564CC825.6080609@redhat.com> Unknown wrote: > I'm new here so first of all want to say hello to everyone. > > I'm implementing FreeIPA in our environment. Everything was fine till i > figure out listing of one domain stops working. When im trying to list > zone via web panel i'm getting "Internal Server Error". It is happening > only for default one zone/domain which is used by kerberos too. Here are > http error logs: > > [Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The > timeout specified has expired: [client 172.16.0.117:48072] mod_wsgi > (pid=11045): Unable to get bucket brigade for request., referer: > https://freeipa01.domain.local/ipa/ui/ > [Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR: > non-public: IOError: request data read error > [Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback (most > recent call last): > [Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 339, in > wsgi_execute > [Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929] data = > read_input(environ) > [Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 187, in > read_input > [Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929] return > environ['wsgi.input'].read(length) > [Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError: request > data read error > [Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO: > [jsonserver_session] admin at DOMAIN.LOCAL : > None: IOError > [Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote > 172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred processing > WSGI script '/usr/share/ipa/wsgi.py'. > [Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote > 172.16.0.117:164] IOError: failed to write data More context would be helpful. I'm assuming that this took a VERY long time to execute? It looks like the wsgi request timed out. Can you duplicate this on the CLI using the ipa tool? > I realize that it stops working after i try to add Ubuntu instance but > Ubuntu client is not work properly. What is strange when im using > command client i don't have problem to list it. I'm not sure I follow. Was it a coincidence after registering an Ubuntu client or do you think it's the cause? rob From rcritten at redhat.com Wed Nov 18 19:28:01 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Nov 2015 14:28:01 -0500 Subject: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups In-Reply-To: <7A7F90629CCF9D488E23F893AF37FEF91FD5CCD9@G9W0717.americas.hpqcorp.net> References: <7A7F90629CCF9D488E23F893AF37FEF91FD5BCA2@G9W0717.americas.hpqcorp.net> <564CAD64.8080608@redhat.com> <7A7F90629CCF9D488E23F893AF37FEF91FD5CCD9@G9W0717.americas.hpqcorp.net> Message-ID: <564CD141.6080207@redhat.com> Sparks, Alan wrote: > >>> [root at als-centos0002 sys-ops]# nisdomainname >>> dakar.useast.hpcloud.net >>> >>> [root at als-centos0002 sys-ops]# getent netgroup opsauto >>> opsauto >>> (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal) >>> (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal) >> > >> Your NIS domain name doesn't match. dakar.useast.hpcloud.net != eucalyptus.internal >> rob > > Thanks for that. I must be misunderstanding the purpose of the --domain option. > -Alan > --domain in the server is the default DNS zone for the IPA installation. --domain in the client tells it where to look for the IPA server in DNS. There is no actual NIS domain but since netgroups are a NIS construct it requires something to be set. The NIS domain needs to match the IPA server domain. rob From mkosek at redhat.com Wed Nov 18 19:34:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Nov 2015 20:34:57 +0100 Subject: [Freeipa-users] service account for ovirt In-Reply-To: References: <564C9086.901@redhat.com> Message-ID: <564CD2E1.8040308@redhat.com> On 11/18/2015 04:27 PM, Rob Verduijn wrote: > 2015-11-18 15:51 GMT+01:00 Martin Kosek : >> On 11/18/2015 08:23 AM, Rob Verduijn wrote: >>> Hello all, >>> >>> I've read a lot regarding service accounts on this mailinglist in the past. >>> But it's rather unclear to me what is the current preffered method to >>> create a service account for a service running on a different machine. >>> >>> In this case it would be a service account for ovirt so that freeipa >>> users can authenticate in the ovirt portal using their freeipa >>> credentials. >> >> It sounds like that you do not want system user account, but you are OK with >> service account so that you can get a keytab for your oVirt instance. In that >> case, simple >> >> $ ipa service-add HTTP/frontend.ovirt.test >> and >> $ ipa-getkeytab ... >> should be enough, right? >> >> Maybe I just do not understand the use case. >> >>> I could ofcourse create an account and then apply a ldf to set its >>> password expiration to the next millennium to make sure the password >>> does not expire. >>> >>> Anybody who has a good suggestion on how to deal with this ? >>> >>> Cheers >>> Rob Verduijn >>> >> > > > > Hello, > > I think some more context should clear this up a bit. > > according to the rhev administrator guide: (ovirt referes to rhev manuals a lot) > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html > > It talks about two options as a single sign on solution. > > On have the single sign on work for the portal, but then it won't work > for the vm's. > ( something about not being able to pass a password since the portal > won't have one to pass ) > > Or have the single sign on work for the vm's but than you have to sign > in to the portal so it can pass on your credentials to the vm's. > > I guess there is some interesting technical challenge to deal with to > merge those two cases. > > The first option requires privileges to browse the freeipa directory > to look for user accounts. > I do not know if that can be solved with something as simple as a > keytab and a pricipal. > > My current working solution is an account with a very long password > experation time in the freeipa directory > ( a random 32 character/number password is being used for this ) > > However something tells me that there is a more elegant solution. > And I was wondering if anyone knows one. Reading the HowTo, I think using normal FreeIPA POSIX user with password policy, uid, home and all the rings and bells may be an over kill. You could replica what is done with sudo system user for binding to LDAP for example: # ldapmodify -D "cn=Directory Manager" -x -W dn: uid=ovirt,cn=sysaccounts,cn=etc,$SUFFIX changetype: add objectclass: account objectclass: simplesecurityobject uid: sudo userPassword: $YOUR_PASSWORD passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0 and use that as oVirt BIND user. As for keytab, you just would not use kadmin, but rather add the service object with "service-add" and get the keytab with "ipa-getkeytab". Other than that, the HowTo was mostly about oVirt side of configuration. If you succeed, it would nice to record your steps specific to FreeIPA in a HowTo article on FreeIPA :-) http://www.freeipa.org/page/HowTos http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki Martin From xuezhiy at gmail.com Mon Nov 16 09:35:03 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Mon, 16 Nov 2015 17:35:03 +0800 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: References: <56494C60.7040709@redhat.com> Message-ID: Rob, where can I get more error information beside the log? [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) 2015-11-16 13:43 GMT+08:00 zhiyong xue : > I am using IPA 4.1 in CenOS7. And I can login to system after "id > syncopex5", maybe it's cache problem. > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden : > >> zhiyong xue wrote: >> > We integrated the Apache Syncope server with FreeIPA server. So user can >> > self register ID from Apache Syncope then synchronize to FreeIPA. The >> > problems are: >> > *1) User created from Apache Syncope can't login to linux. The user >> > created from FreeIPA web gui works well.* >> >> For login issues see https://fedorahosted.org/sssd/wiki/Troubleshooting >> This is unlikely to fix things but it will help with later debugging. >> >> This likely revolves around how you are creating these accounts. We'll >> need information on what you're doing. The more details the better. >> >> > *2) The user also can't be deleted from web UI and CLI. It said >> > "syncopex5: user not found".* >> >> Again, you probably aren't creating the users correctly. >> >> I can only assume that you are creating the users directly via an LDAP >> add. This is working around the IPA framework which does additional work. >> >> Knowing what version of IPA this is would help too. >> >> You'll probably also want to read this: >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is in >> IPA 4.2. >> >> rob >> rob >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.lamb at ch.ibm.com Thu Nov 19 09:02:14 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Thu, 19 Nov 2015 10:02:14 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <20151118182827.GL2986@hendrix> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> <20151118182827.GL2986@hendrix> Message-ID: <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> Hi Jakub I have restarted sssd with debug_level=6 Then I made one (failed) attempt to login via ssh with the user "bimbo". Logs, anonymised are attached. To my untrained eyes, nothing shouts "horrible error" to me. Chris (See attached file: sssd_logs.zip) From: Jakub Hrozek To: freeipa-users at redhat.com Date: 18.11.2015 19:30 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 Sent by: freeipa-users-bounces at redhat.com On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to 7.1) > The ipa-client is installed, making this server an ipa host. > > > > > getent passwd xxxx > > is successful for ipa users. -->OK > > However I cannot log on to the host with ipa users (direct or ssh). --> NOT > > OK > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > "> systemctl status sssd" and "> kinit" > > both show: > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > Having googled with this error, I saw some indications that it could be > > related to the kernel. > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > thought, let?s change back to the standard RHEL kernel. > > After a reboot with the RHEL kernel, I was still not able to log in with my > > ipa user. > > > > I then logged on as root, and changed to my ipa user via su. > > > klist -l > > produced: > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) I'm surprised you had any ccache at all, because login as root bypasses PAM. But in general, if you login with sssd and the cache is expired a long time ago (1970), that means sssd logged you in offline and the ccache is a placeholder for when sssd switches to online mode. > > > > I therefore deleted the key: > > > kdestroy -A > > Then I stopped the sssd service, and cleared the cache in /var/lib/sss/db/, > > then restarted sssd > > > > After that I was now able to log on with my ipa user (both direct and via > > ssh). > > > > However I cannot get any other ipa users to logon to this host! --> NOT OK > > The same users can successfully logon to other ipa hosts in the same > > domain. > > > > My ipa user was the one used to enroll the host. > > > > Any ideas? Not without logs, see: https://fedorahosted.org/sssd/wiki/Troubleshooting -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_logs.zip Type: application/zip Size: 13502 bytes Desc: not available URL: From christopher.lamb at ch.ibm.com Thu Nov 19 09:25:02 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Thu, 19 Nov 2015 10:25:02 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com><20151118182827.GL2986@hendrix> <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> Message-ID: <201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com> HI The plot thickens. I think I actually have 2 issues: The first issue is that in the title of this thread, and was caused by "the wrong kernel". The second issue, that some ipa users cannot log on (but mine can), is (probably) unrelated. The clue was my point below "no obvious horrible error". That led my to look in /var/log/secure, where I found the following: Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxxxxx.my-domain.xx.domain.com user=bimbo Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "bimbo" Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from 9.164.17.110 port 49332 ssh2 Both my user, and an additional test user this morning have uids > 1000, and can successfully login -->OK The 2 other users I tested with yesterday (one application user, and one real user) have ids < 1000, and therefore (on this host) cannot logon. Now I need to google further to find where this rule is configured / hidden. Cheers Chris From: Christopher Lamb/Switzerland/IBM at IBMCH To: Jakub Hrozek Cc: freeipa-users at redhat.com Date: 19.11.2015 10:05 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 Sent by: freeipa-users-bounces at redhat.com Hi Jakub I have restarted sssd with debug_level=6 Then I made one (failed) attempt to login via ssh with the user "bimbo". Logs, anonymised are attached. To my untrained eyes, nothing shouts "horrible error" to me. Chris (See attached file: sssd_logs.zip) Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > From: Jakub Hrozek To: freeipa-users at redhat.com Date: 18.11.2015 19:30 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 Sent by: freeipa-users-bounces at redhat.com On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to 7.1) > The ipa-client is installed, making this server an ipa host. > > > > > getent passwd xxxx > > is successful for ipa users. -->OK > > However I cannot log on to the host with ipa users (direct or ssh). --> NOT > > OK > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > "> systemctl status sssd" and "> kinit" > > both show: > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > Having googled with this error, I saw some indications that it could be > > related to the kernel. > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > thought, let?s change back to the standard RHEL kernel. > > After a reboot with the RHEL kernel, I was still not able to log in with my > > ipa user. > > > > I then logged on as root, and changed to my ipa user via su. > > > klist -l > > produced: > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) I'm surprised you had any ccache at all, because login as root bypasses PAM. But in general, if you login with sssd and the cache is expired a long time ago (1970), that means sssd logged you in offline and the ccache is a placeholder for when sssd switches to online mode. > > > > I therefore deleted the key: > > > kdestroy -A > > Then I stopped the sssd service, and cleared the cache in /var/lib/sss/db/, > > then restarted sssd > > > > After that I was now able to log on with my ipa user (both direct and via > > ssh). > > > > However I cannot get any other ipa users to logon to this host! --> NOT OK > > The same users can successfully logon to other ipa hosts in the same > > domain. > > > > My ipa user was the one used to enroll the host. > > > > Any ideas? Not without logs, see: https://fedorahosted.org/sssd/wiki/Troubleshooting -- 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 [attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From sbose at redhat.com Thu Nov 19 09:38:38 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 19 Nov 2015 10:38:38 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> <20151118182827.GL2986@hendrix> <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> <201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com> Message-ID: <20151119093838.GD3342@p.redhat.com> On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote: > HI > > The plot thickens. I think I actually have 2 issues: > > The first issue is that in the title of this thread, and was caused by "the > wrong kernel". > > The second issue, that some ipa users cannot log on (but mine can), is > (probably) unrelated. > > The clue was my point below "no obvious horrible error". > > That led my to look in /var/log/secure, where I found the following: > > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=xxxxxx.my-domain.xx.domain.com user=bimbo > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth): > requirement "uid >= 1000" not met by user "bimbo" > Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from > 9.164.17.110 port 49332 ssh2 > > Both my user, and an additional test user this morning have uids > 1000, > and can successfully login -->OK > > The 2 other users I tested with yesterday (one application user, and one > real user) have ids < 1000, and therefore (on this host) cannot logon. > > Now I need to google further to find where this rule is configured / > hidden. The '1000' is written by authconfig into the pam configuration. Afaik authconfig uses the UID_MIN form /etc/login.defs here. HTH bye, Sumit > > Cheers > > Chris > > > > > > From: Christopher Lamb/Switzerland/IBM at IBMCH > To: Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 19.11.2015 10:05 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name > while getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > Hi Jakub > > I have restarted sssd with debug_level=6 > > Then I made one (failed) attempt to login via ssh with the user "bimbo". > > Logs, anonymised are attached. > > To my untrained eyes, nothing shouts "horrible error" to me. > > Chris > > (See attached file: sssd_logs.zip) > > > Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov > 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek > ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, > Christopher Lamb wrote: > > > From: Jakub Hrozek > To: freeipa-users at redhat.com > Date: 18.11.2015 19:30 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while > getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to > 7.1) > > The ipa-client is installed, making this server an ipa host. > > > > > > > > > getent passwd xxxx > > > > is successful for ipa users. -->OK > > > > However I cannot log on to the host with ipa users (direct or ssh). --> > NOT > > > > OK > > > > > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > > > > > "> systemctl status sssd" and "> kinit" > > > > both show: > > > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > > > > > Having googled with this error, I saw some indications that it could be > > > > related to the kernel. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > > > thought, let?s change back to the standard RHEL kernel. > > > > After a reboot with the RHEL kernel, I was still not able to log in with > my > > > > ipa user. > > > > > > > > I then logged on as root, and changed to my ipa user via su. > > > > > klist -l > > > > produced: > > > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) > > I'm surprised you had any ccache at all, because login as root bypasses > PAM. > > But in general, if you login with sssd and the cache is expired a long > time ago (1970), that means sssd logged you in offline and the ccache is > a placeholder for when sssd switches to online mode. > > > > > > > > > I therefore deleted the key: > > > > > kdestroy -A > > > > Then I stopped the sssd service, and cleared the cache > in /var/lib/sss/db/, > > > > then restarted sssd > > > > > > > > After that I was now able to log on with my ipa user (both direct and via > > > > ssh). > > > > > > > > However I cannot get any other ipa users to logon to this host! --> NOT > OK > > > > The same users can successfully logon to other ipa hosts in the same > > > > domain. > > > > > > > > My ipa user was the one used to enroll the host. > > > > > > > > Any ideas? > > Not without logs, see: > https://fedorahosted.org/sssd/wiki/Troubleshooting > > -- > 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 > > [attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] -- > > 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 From christopher.lamb at ch.ibm.com Thu Nov 19 10:17:48 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Thu, 19 Nov 2015 11:17:48 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <20151119093838.GD3342@p.redhat.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> <20151118182827.GL2986@hendrix> <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> <201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com> <20151119093838.GD3342@p.redhat.com> Message-ID: <201511191018.tAJAIlNs018491@d06av06.portsmouth.uk.ibm.com> Hi Sumit Thanks, I too have found /etc/login.defs https://fedoraproject.org/wiki/Features/1000SystemAccounts I have changed the UID_MIN to 500, and rebooted, but it seems to have no effect. Reading between the lines in the link above, it looks like this value may have to be set pre-install. Maybe I need to do something else to change the value? Chris From: Sumit Bose To: Christopher Lamb/Switzerland/IBM at IBMCH Cc: Jakub Hrozek , freeipa-users at redhat.com Date: 19.11.2015 10:38 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote: > HI > > The plot thickens. I think I actually have 2 issues: > > The first issue is that in the title of this thread, and was caused by "the > wrong kernel". > > The second issue, that some ipa users cannot log on (but mine can), is > (probably) unrelated. > > The clue was my point below "no obvious horrible error". > > That led my to look in /var/log/secure, where I found the following: > > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=xxxxxx.my-domain.xx.domain.com user=bimbo > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth): > requirement "uid >= 1000" not met by user "bimbo" > Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from > 9.164.17.110 port 49332 ssh2 > > Both my user, and an additional test user this morning have uids > 1000, > and can successfully login -->OK > > The 2 other users I tested with yesterday (one application user, and one > real user) have ids < 1000, and therefore (on this host) cannot logon. > > Now I need to google further to find where this rule is configured / > hidden. The '1000' is written by authconfig into the pam configuration. Afaik authconfig uses the UID_MIN form /etc/login.defs here. HTH bye, Sumit > > Cheers > > Chris > > > > > > From: Christopher Lamb/Switzerland/IBM at IBMCH > To: Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 19.11.2015 10:05 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name > while getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > Hi Jakub > > I have restarted sssd with debug_level=6 > > Then I made one (failed) attempt to login via ssh with the user "bimbo". > > Logs, anonymised are attached. > > To my untrained eyes, nothing shouts "horrible error" to me. > > Chris > > (See attached file: sssd_logs.zip) > > > Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov > 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek > ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, > Christopher Lamb wrote: > > > From: Jakub Hrozek > To: freeipa-users at redhat.com > Date: 18.11.2015 19:30 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while > getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to > 7.1) > > The ipa-client is installed, making this server an ipa host. > > > > > > > > > getent passwd xxxx > > > > is successful for ipa users. -->OK > > > > However I cannot log on to the host with ipa users (direct or ssh). --> > NOT > > > > OK > > > > > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > > > > > "> systemctl status sssd" and "> kinit" > > > > both show: > > > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > > > > > Having googled with this error, I saw some indications that it could be > > > > related to the kernel. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > > > thought, let?s change back to the standard RHEL kernel. > > > > After a reboot with the RHEL kernel, I was still not able to log in with > my > > > > ipa user. > > > > > > > > I then logged on as root, and changed to my ipa user via su. > > > > > klist -l > > > > produced: > > > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) > > I'm surprised you had any ccache at all, because login as root bypasses > PAM. > > But in general, if you login with sssd and the cache is expired a long > time ago (1970), that means sssd logged you in offline and the ccache is > a placeholder for when sssd switches to online mode. > > > > > > > > > I therefore deleted the key: > > > > > kdestroy -A > > > > Then I stopped the sssd service, and cleared the cache > in /var/lib/sss/db/, > > > > then restarted sssd > > > > > > > > After that I was now able to log on with my ipa user (both direct and via > > > > ssh). > > > > > > > > However I cannot get any other ipa users to logon to this host! --> NOT > OK > > > > The same users can successfully logon to other ipa hosts in the same > > > > domain. > > > > > > > > My ipa user was the one used to enroll the host. > > > > > > > > Any ideas? > > Not without logs, see: > https://fedorahosted.org/sssd/wiki/Troubleshooting > > -- > 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 > > [attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From christopher.lamb at ch.ibm.com Thu Nov 19 10:28:10 2015 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Thu, 19 Nov 2015 11:28:10 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <201511191018.tAJAIlNs018491@d06av06.portsmouth.uk.ibm.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com><20151118182827.GL2986@hendrix><201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com><201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com><20151119093838.GD3342@p.redhat.com> <201511191018.tAJAIlNs018491@d06av06.portsmouth.uk.ibm.com> Message-ID: <201511191029.tAJATENp015372@d06av06.portsmouth.uk.ibm.com> Now it works: First I edited /etc/login.defs UID_MIN to 500 Then I ran "authconfig --update" to make the change(s) to login.defs active. After that, users with uids >=500 were able to login again. In our case we have both system users (application) and "long term employees, user account predates LDAP" with such low ids. Chris From: Christopher Lamb/Switzerland/IBM at IBMCH To: Sumit Bose Cc: freeipa-users at redhat.com Date: 19.11.2015 11:20 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 Sent by: freeipa-users-bounces at redhat.com Hi Sumit Thanks, I too have found /etc/login.defs https://fedoraproject.org/wiki/Features/1000SystemAccounts I have changed the UID_MIN to 500, and rebooted, but it seems to have no effect. Reading between the lines in the link above, it looks like this value may have to be set pre-install. Maybe I need to do something else to change the value? Chris Inactive hide details for Sumit Bose ---19.11.2015 10:38:49---On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:Sumit Bose ---19.11.2015 10:38:49---On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote: > HI From: Sumit Bose To: Christopher Lamb/Switzerland/IBM at IBMCH Cc: Jakub Hrozek , freeipa-users at redhat.com Date: 19.11.2015 10:38 Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote: > HI > > The plot thickens. I think I actually have 2 issues: > > The first issue is that in the title of this thread, and was caused by "the > wrong kernel". > > The second issue, that some ipa users cannot log on (but mine can), is > (probably) unrelated. > > The clue was my point below "no obvious horrible error". > > That led my to look in /var/log/secure, where I found the following: > > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=xxxxxx.my-domain.xx.domain.com user=bimbo > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth): > requirement "uid >= 1000" not met by user "bimbo" > Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from > 9.164.17.110 port 49332 ssh2 > > Both my user, and an additional test user this morning have uids > 1000, > and can successfully login -->OK > > The 2 other users I tested with yesterday (one application user, and one > real user) have ids < 1000, and therefore (on this host) cannot logon. > > Now I need to google further to find where this rule is configured / > hidden. The '1000' is written by authconfig into the pam configuration. Afaik authconfig uses the UID_MIN form /etc/login.defs here. HTH bye, Sumit > > Cheers > > Chris > > > > > > From: Christopher Lamb/Switzerland/IBM at IBMCH > To: Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 19.11.2015 10:05 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name > while getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > Hi Jakub > > I have restarted sssd with debug_level=6 > > Then I made one (failed) attempt to login via ssh with the user "bimbo". > > Logs, anonymised are attached. > > To my untrained eyes, nothing shouts "horrible error" to me. > > Chris > > (See attached file: sssd_logs.zip) > > > Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov > 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek > ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, > Christopher Lamb wrote: > > > From: Jakub Hrozek > To: freeipa-users at redhat.com > Date: 18.11.2015 19:30 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while > getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to > 7.1) > > The ipa-client is installed, making this server an ipa host. > > > > > > > > > getent passwd xxxx > > > > is successful for ipa users. -->OK > > > > However I cannot log on to the host with ipa users (direct or ssh). --> > NOT > > > > OK > > > > > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > > > > > "> systemctl status sssd" and "> kinit" > > > > both show: > > > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > > > > > Having googled with this error, I saw some indications that it could be > > > > related to the kernel. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > > > thought, let?s change back to the standard RHEL kernel. > > > > After a reboot with the RHEL kernel, I was still not able to log in with > my > > > > ipa user. > > > > > > > > I then logged on as root, and changed to my ipa user via su. > > > > > klist -l > > > > produced: > > > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) > > I'm surprised you had any ccache at all, because login as root bypasses > PAM. > > But in general, if you login with sssd and the cache is expired a long > time ago (1970), that means sssd logged you in offline and the ccache is > a placeholder for when sssd switches to online mode. > > > > > > > > > I therefore deleted the key: > > > > > kdestroy -A > > > > Then I stopped the sssd service, and cleared the cache > in /var/lib/sss/db/, > > > > then restarted sssd > > > > > > > > After that I was now able to log on with my ipa user (both direct and via > > > > ssh). > > > > > > > > However I cannot get any other ipa users to logon to this host! --> NOT > OK > > > > The same users can successfully logon to other ipa hosts in the same > > > > domain. > > > > > > > > My ipa user was the one used to enroll the host. > > > > > > > > Any ideas? > > Not without logs, see: > https://fedorahosted.org/sssd/wiki/Troubleshooting > > -- > 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 > > [attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From sbose at redhat.com Thu Nov 19 11:14:39 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 19 Nov 2015 12:14:39 +0100 Subject: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1 In-Reply-To: <201511191028.tAJASIiS006735@d06av09.portsmouth.uk.ibm.com> References: <201511181535.tAIFZcK3029314@d06av09.portsmouth.uk.ibm.com> <20151118182827.GL2986@hendrix> <201511190803.tAJ83Yjx020205@d06av10.portsmouth.uk.ibm.com> <201511190926.tAJ9Q3hg018115@d06av08.portsmouth.uk.ibm.com> <20151119093838.GD3342@p.redhat.com> <201511191018.tAJAIlNs018491@d06av06.portsmouth.uk.ibm.com> <201511191028.tAJASIiS006735@d06av09.portsmouth.uk.ibm.com> Message-ID: <20151119111439.GE3342@p.redhat.com> On Thu, Nov 19, 2015 at 11:28:10AM +0100, Christopher Lamb wrote: > Now it works: > > First I edited /etc/login.defs UID_MIN to 500 > > Then I ran "authconfig --update" to make the change(s) to login.defs > active. yes, it is expected that you have to run authconfig after changing the value in login.defs to update the pam configuration. bye, Sumit > > After that, users with uids >=500 were able to login again. > > In our case we have both system users (application) and "long term > employees, user account predates LDAP" with such low ids. > > Chris > > > > From: Christopher Lamb/Switzerland/IBM at IBMCH > To: Sumit Bose > Cc: freeipa-users at redhat.com > Date: 19.11.2015 11:20 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name > while getting default cache. on OEL 7.1 > Sent by: freeipa-users-bounces at redhat.com > > > > Hi Sumit > > Thanks, I too have found /etc/login.defs > > https://fedoraproject.org/wiki/Features/1000SystemAccounts > > I have changed the UID_MIN to 500, and rebooted, but it seems to have no > effect. > > Reading between the lines in the link above, it looks like this value may > have to be set pre-install. > > Maybe I need to do something else to change the value? > > Chris > > > > > > Inactive hide details for Sumit Bose ---19.11.2015 10:38:49---On Thu, Nov > 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:Sumit Bose > ---19.11.2015 10:38:49---On Thu, Nov 19, 2015 at 10:25:02AM +0100, > Christopher Lamb wrote: > HI > > From: Sumit Bose > To: Christopher Lamb/Switzerland/IBM at IBMCH > Cc: Jakub Hrozek , freeipa-users at redhat.com > Date: 19.11.2015 10:38 > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while > getting default cache. on OEL 7.1 > > > > On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote: > > HI > > > > The plot thickens. I think I actually have 2 issues: > > > > The first issue is that in the title of this thread, and was caused by > "the > > wrong kernel". > > > > The second issue, that some ipa users cannot log on (but mine can), is > > (probably) unrelated. > > > > The clue was my point below "no obvious horrible error". > > > > That led my to look in /var/log/secure, where I found the following: > > > > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= > > rhost=xxxxxx.my-domain.xx.domain.com user=bimbo > > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth): > > requirement "uid >= 1000" not met by user "bimbo" > > Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from > > 9.164.17.110 port 49332 ssh2 > > > > Both my user, and an additional test user this morning have uids > 1000, > > and can successfully login -->OK > > > > The 2 other users I tested with yesterday (one application user, and one > > real user) have ids < 1000, and therefore (on this host) cannot logon. > > > > Now I need to google further to find where this rule is configured / > > hidden. > > The '1000' is written by authconfig into the pam configuration. Afaik > authconfig uses the UID_MIN form /etc/login.defs here. > > HTH > > bye, > Sumit > > > > > Cheers > > > > Chris > > > > > > > > > > > > From: Christopher Lamb/Switzerland/IBM at IBMCH > > To: Jakub Hrozek > > Cc: freeipa-users at redhat.com > > Date: 19.11.2015 10:05 > > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name > > while getting default cache. on OEL 7.1 > > Sent by: freeipa-users-bounces at redhat.com > > > > > > > > Hi Jakub > > > > I have restarted sssd with debug_level=6 > > > > Then I made one (failed) attempt to login via ssh with the user "bimbo". > > > > Logs, anonymised are attached. > > > > To my untrained eyes, nothing shouts "horrible error" to me. > > > > Chris > > > > (See attached file: sssd_logs.zip) > > > > > > Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, > Nov > > 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek > > ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100, > > Christopher Lamb wrote: > > > > > From: Jakub Hrozek > > To: freeipa-users at redhat.com > > Date: 18.11.2015 19:30 > > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while > > getting default cache. on OEL 7.1 > > Sent by: freeipa-users-bounces at redhat.com > > > > > > > > On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote: > > > > > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to > > 7.1) > > > The ipa-client is installed, making this server an ipa host. > > > > > > > > > > > > > getent passwd xxxx > > > > > > is successful for ipa users. -->OK > > > > > > However I cannot log on to the host with ipa users (direct or ssh). --> > > NOT > > > > > > OK > > > > > > > > > > > > When logged on as root (local user), I can ?su -? to my ipa user. -->OK > > > > > > > > > > > > "> systemctl status sssd" and "> kinit" > > > > > > both show: > > > > > > ?Invalid UID in persistent keyring name while getting default cache.? > > > > > > > > > > > > Having googled with this error, I saw some indications that it could be > > > > > > related to the kernel. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1017683 > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1029110 > > > > > > > > > > > > For a fresh OEL install, the default kernel is the uek version. "Aha" I > > > > > > thought, let?s change back to the standard RHEL kernel. > > > > > > After a reboot with the RHEL kernel, I was still not able to log in > with > > my > > > > > > ipa user. > > > > > > > > > > > > I then logged on as root, and changed to my ipa user via su. > > > > > > > klist -l > > > > > > produced: > > > > > > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired) > > > > I'm surprised you had any ccache at all, because login as root bypasses > > PAM. > > > > But in general, if you login with sssd and the cache is expired a long > > time ago (1970), that means sssd logged you in offline and the ccache is > > a placeholder for when sssd switches to online mode. > > > > > > > > > > > > > > I therefore deleted the key: > > > > > > > kdestroy -A > > > > > > Then I stopped the sssd service, and cleared the cache > > in /var/lib/sss/db/, > > > > > > then restarted sssd > > > > > > > > > > > > After that I was now able to log on with my ipa user (both direct and > via > > > > > > ssh). > > > > > > > > > > > > However I cannot get any other ipa users to logon to this host! --> > NOT > > OK > > > > > > The same users can successfully logon to other ipa hosts in the same > > > > > > domain. > > > > > > > > > > > > My ipa user was the one used to enroll the host. > > > > > > > > > > > > Any ideas? > > > > Not without logs, see: > > https://fedorahosted.org/sssd/wiki/Troubleshooting > > > > -- > > 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 > > > > [attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] > -- > > > > 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 > From holosian at gmail.com Thu Nov 19 07:11:38 2015 From: holosian at gmail.com (holo) Date: Thu, 19 Nov 2015 08:11:38 +0100 Subject: [Freeipa-users] FreeIPA Internal Server Error In-Reply-To: <1447915920.16740.13.camel@gmail.com> References: <1447857157.3197.13.camel@gmail.com> <564CC825.6080609@redhat.com> <1447915920.16740.13.camel@gmail.com> Message-ID: <1447917098.16740.21.camel@gmail.com> I checked again my web UI and it starts working - i really did not change anything. Right now i'm getting list of records immediately without "Waiting" inscription and no errors in log file. What could be a reason of such behave, how to fix it if it appear again? I think problem was that long execute time like Rob wrote, but what might have caused it? On Thu, 2015-11-19 at 07:52 +0100, Unknown wrote: > On Wed, 2015-11-18 at 13:49 -0500, Rob Crittenden wrote: > > Unknown wrote: > > > I'm new here so first of all want to say hello to everyone. > > > > > > I'm implementing FreeIPA in our environment. Everything was fine > > > till i > > > figure out listing of one domain stops working. When im trying to > > > list > > > zone via web panel i'm getting "Internal Server Error". It is > > > happening > > > only for default one zone/domain which is used by kerberos too. > > > Here are > > > http error logs: > > > > > > [Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The > > > timeout specified has expired: [client 172.16.0.117:48072] > > > mod_wsgi > > > (pid=11045): Unable to get bucket brigade for request., referer: > > > https://freeipa01.domain.local/ipa/ui/ > > > [Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR: > > > non-public: IOError: request data read error > > > [Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback > > > (most > > > recent call last): > > > [Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929]???File > > > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > > > 339, in > > > wsgi_execute > > > [Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929]?????data = > > > read_input(environ) > > > [Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929]???File > > > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > > > 187, in > > > read_input > > > [Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929]?????return > > > environ['wsgi.input'].read(length) > > > [Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError: > > > request > > > data read error > > > [Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO: > > > [jsonserver_session] admin at DOMAIN.LOCAL > > > L>: > > > None: IOError > > > [Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote > > > 172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred > > > processing > > > WSGI script '/usr/share/ipa/wsgi.py'. > > > [Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote > > > 172.16.0.117:164] IOError: failed to write data > > > > More context would be helpful. I'm assuming that this took a VERY > > long > > time to execute? It looks like the wsgi request timed out. > > > > Can you duplicate this on the CLI using the ipa tool? > > > CLI is working without any problems i can list, add, delete records, > problem only appear in web interface when i want to list my default > ?zone (others are working for now). > > According to that long time execute. Internal server error appears > for around 10 sec. I'm not familiar with wsgi but i tried to add > "?inactivity-timeout=60" option to "WSGIDaemonProcess" in ipa.conf > like bellow: > > WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 > inactivity-timeout=60 > > but it did not help. > > > > > I realize that it stops working after i try to add Ubuntu > > > instance but > > > Ubuntu client is not work properly. What is strange when im using > > > command client i don't have problem to list it. > > > > I'm not sure I follow. Was it a coincidence after registering an > > Ubuntu > > client or do you think it's the cause? > I noticed it after i tried to add ubuntu instance to my freeipa maybe > this is not connected with it. > > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From PatrickCProvenzo at Eaton.com Thu Nov 19 15:28:30 2015 From: PatrickCProvenzo at Eaton.com (PatrickCProvenzo at Eaton.com) Date: Thu, 19 Nov 2015 15:28:30 +0000 Subject: [Freeipa-users] proftpd with ipa Message-ID: I cannot get proftpd to authenticate with IPA. I received the following messages in /var/log/secure proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER e0026887: no such user found from 151.##.##.## [151.##.##.##] to 151.##.##.## Here are all the versions I have installed RHEL - 6.7 IPA - 3.0.0-47.el6 proftpd.x86_64 1.3.3g-4.el6 proftpd-ldap.x86_64 1.3.3g-4.el6 I have attached my proftpd.conf file also. Patrick Provenzo www.eaton.com Specialist.IT.EIS-E.Design & Engineering patrickcprovenzo at eaton.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: proftpd.conf Type: application/octet-stream Size: 9942 bytes Desc: proftpd.conf URL: From rcritten at redhat.com Thu Nov 19 15:50:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Nov 2015 10:50:42 -0500 Subject: [Freeipa-users] proftpd with ipa In-Reply-To: References: Message-ID: <564DEFD2.2010801@redhat.com> PatrickCProvenzo at Eaton.com wrote: > I cannot get proftpd to authenticate with IPA. I received the following > messages in /var/log/secure > > > > proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER > e0026887: no such user found from 151.##.##.## [151.##.##.##] to > 151.##.##.## > Just throwing this out there, but what HBAC rules do you have? Do you still have the allow_all rule enabled? rob > > > Here are all the versions I have installed > > > > RHEL ? 6.7 > > IPA - 3.0.0-47.el6 > > proftpd.x86_64 1.3.3g-4.el6 > > proftpd-ldap.x86_64 1.3.3g-4.el6 > > > > I have attached my proftpd.conf file also. > > > > Patrick Provenzo > > www.eaton.com > > Specialist.IT.EIS-E.Design & Engineering** > > patrickcprovenzo at eaton.com > > > > > From rcritten at redhat.com Thu Nov 19 16:11:04 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Nov 2015 11:11:04 -0500 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: References: <56494C60.7040709@redhat.com> Message-ID: <564DF498.40209@redhat.com> zhiyong xue wrote: > Rob, where can I get more error information beside the log? > [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: > failed to delete managed entry > (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) I can still only assume what you're doing: manually adding the entries directly by LDAP. To do this you need to follow IPA conventions, or use the new user lifecycle framework added in 4.2. I'm guessing it can't delete the managed entry because either it doesn't exist or it is missing an objectclass/attribute marking it as managed. rob > > 2015-11-16 13:43 GMT+08:00 zhiyong xue >: > > I am using IPA 4.1 in CenOS7. And I can login to system after "id > syncopex5", maybe it's cache problem. > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden >: > > zhiyong xue wrote: > > We integrated the Apache Syncope server with FreeIPA server. So user can > > self register ID from Apache Syncope then synchronize to FreeIPA. The > > problems are: > > *1) User created from Apache Syncope can't login to linux. The > user > > created from FreeIPA web gui works well.* > > For login issues see > https://fedorahosted.org/sssd/wiki/Troubleshooting > This is unlikely to fix things but it will help with later > debugging. > > This likely revolves around how you are creating these accounts. > We'll > need information on what you're doing. The more details the better. > > > *2) The user also can't be deleted from web UI and CLI. It said > > "syncopex5: user not found".* > > Again, you probably aren't creating the users correctly. > > I can only assume that you are creating the users directly via > an LDAP > add. This is working around the IPA framework which does > additional work. > > Knowing what version of IPA this is would help too. > > You'll probably also want to read this: > http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This > is in > IPA 4.2. > > rob > rob > > > From rcritten at redhat.com Thu Nov 19 16:32:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Nov 2015 11:32:32 -0500 Subject: [Freeipa-users] proftpd with ipa In-Reply-To: References: <564DEFD2.2010801@redhat.com> Message-ID: <564DF9A0.3070606@redhat.com> PatrickCProvenzo at Eaton.com wrote: > I don't have that one enabled. I have use one that allows only my Unix admins to have access to all systems. Ok, I'd start with typical SSSD troubleshooting then: https://fedorahosted.org/sssd/wiki/Troubleshooting rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, November 19, 2015 10:51 AM > To: Provenzo, Patrick C; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] proftpd with ipa > > PatrickCProvenzo at Eaton.com wrote: >> I cannot get proftpd to authenticate with IPA. I received the >> following messages in /var/log/secure >> >> >> >> proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER >> e0026887: no such user found from 151.##.##.## [151.##.##.##] to >> 151.##.##.## >> > > Just throwing this out there, but what HBAC rules do you have? Do you still have the allow_all rule enabled? > > rob > >> >> >> Here are all the versions I have installed >> >> >> >> RHEL - 6.7 >> >> IPA - 3.0.0-47.el6 >> >> proftpd.x86_64 1.3.3g-4.el6 >> >> proftpd-ldap.x86_64 1.3.3g-4.el6 >> >> >> >> I have attached my proftpd.conf file also. >> >> >> >> Patrick Provenzo >> >> www.eaton.com >> >> Specialist.IT.EIS-E.Design & Engineering** >> >> patrickcprovenzo at eaton.com >> >> >> >> >> > From jhrozek at redhat.com Thu Nov 19 16:37:08 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Nov 2015 17:37:08 +0100 Subject: [Freeipa-users] proftpd with ipa In-Reply-To: <564DF9A0.3070606@redhat.com> References: <564DEFD2.2010801@redhat.com> <564DF9A0.3070606@redhat.com> Message-ID: <20151119163708.GE4982@hendrix.arn.redhat.com> On Thu, Nov 19, 2015 at 11:32:32AM -0500, Rob Crittenden wrote: > PatrickCProvenzo at Eaton.com wrote: > > I don't have that one enabled. I have use one that allows only my Unix admins to have access to all systems. > > Ok, I'd start with typical SSSD troubleshooting then: > https://fedorahosted.org/sssd/wiki/Troubleshooting > > rob In addition the proftpd message says "no such user", can you resolve the user on the proftpd server with 'getent passwd $username' ? From aalam at paperlesspost.com Thu Nov 19 22:03:48 2015 From: aalam at paperlesspost.com (Ash Alam) Date: Thu, 19 Nov 2015 17:03:48 -0500 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 Message-ID: Hello All I am looking for some advice on upgrading. Currently our FreeIPA servers are 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This upgrade path is not possible per IPA documentation. Minimum version required is 3.3.x. I have also found that cenos6 does not provide anything past 3.0.0. One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 on centos7. This is harder since centos does not provide this. The other issue is if 3.0/3.3 client will be supported with 4.2.3 server. Thank You -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Nov 19 22:35:46 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 19 Nov 2015 23:35:46 +0100 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: References: Message-ID: On Thu, Nov 19, 2015 at 11:03 PM, Ash Alam wrote: > Hello All > > I am looking for some advice on upgrading. Currently our FreeIPA servers > are 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This > upgrade path is not possible per IPA documentation. Minimum version > required is 3.3.x. I have also found that cenos6 does not provide anything > past 3.0.0. > > do you mean upgrading the systems themselves? Why don't you install a centos 7 host and join it as domain controller to the existing realm? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html I have tested the procedure a couple of times and it works really well. I just came up with one issue which you can read here: https://www.redhat.com/archives/freeipa-users/2015-September/thread.html#00161 -- groet, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gil at omnigroup.com Thu Nov 19 23:19:41 2015 From: gil at omnigroup.com (Gilbert Wilson) Date: Thu, 19 Nov 2015 15:19:41 -0800 Subject: [Freeipa-users] Python IndexError: list index out of range with ipa-server-install --external-cert-file In-Reply-To: <563A0CFD.2030901@redhat.com> References: <38A69A03-997C-4A84-8A8E-898156CB6537@omnigroup.com> <563A0CFD.2030901@redhat.com> Message-ID: > On Nov 4, 2015, at 5:49 AM, Rob Crittenden wrote: > > Gilbert Wilson wrote: >> Apologies ahead of time as this is my first post to the list and interaction with the FreeIPA project. If I should be taking this question to a different forum please point me in the right direction! >> >> The error condition I? encountering is mentioned a few times on the list, but the threads die off without any conclusions. The most recent mention of it that I could find is here: >> >> https://www.redhat.com/archives/freeipa-users/2015-March/msg00271.html >> >> It also looks like this has shown up as a bug that was fixed here: >> >> https://fedorahosted.org/freeipa/ticket/4397 >> >> I? using CentOS Linux release 7.1.1503 (Core) system running FreeIPA VERSION: 4.1.0, API_VERSION: 2.112. >> >> The error happens when attempting to finish an ipa-server-install using a cert signed by an external CA: >> >> ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem >> >> The install proceeds as normal, but then when trying to create the RA certificate it errors out with: >> >> ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IndexError: list index out of range >> [root at ipa ?]# ipa : DEBUG stderr= >> all/cainstance.py", line 520, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation >> run_step(full_msg, method) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step >> method() >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1149, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> >> ipa : DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IndexError: list index out of range >> >> Unlike the bug and thread I linked to above we are not using a Windows CA. Our CA is based on openssl. Since I? fairly new to FreeIPA I? not sure what logs would be most helpful to troubleshoot, but my bumbling about seemed to indicate that the the error condition is in the server? xml-based web api request/response logic. I? not sure if the error is localized to that part of the system or if there? some precondition that failed beforehand. The installation is left in a pretty broken/useless state. If I try to run `ipa-server-install -d --external-cert-file=/path/to/certificate.pem --external-cert-file=/path/to/certificate_authority.pem` again it instructs me that I have to run `ipa-server-install --external-ca` (essentially, start over from scratch). An aside question: is there some way to rerun the setup from where it broke down so that I don? have to bother our CA admin to sign my CSR each time? That said, I can reliably produce this error condition and am willing! > to put in > some time to do data collection to track it down, and our CA admin is willing to humor me for a little while! But, where do I start? What information would be most useful to collect? > > You're seeing a symptom, not the problem. You'd need to look at the > install log referenced above plus the debug log somewhere in > /var/log/pki/pki-ca/ > > And unfortunately right now you need to start over after a failed install. Rob, Thanks for the reply. It turns out that there were a couple things wrong, but the biggest one was that the certificate I was getting back from our CA had CA set to false! So yeeeaaahh? *facepalm* once I went on a detour of setting up my own offline root CA with openssl (a nice learning experience) the installation worked as expected. The only thing I can think of on the FreeIPA side that would be helpful is an additional pre-test that read the external certificate and immediately errors out if it finds that basic constraints have been set to CA:false. Gil Gilbert Wilson Systems Administrator The Omni Group +1 206-523-4152 +1 206-523-5896 (Fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mexigabacho at gmail.com Thu Nov 19 23:00:35 2015 From: mexigabacho at gmail.com (Christopher Young) Date: Thu, 19 Nov 2015 18:00:35 -0500 Subject: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1 In-Reply-To: <20151112084546.GH1147@redhat.com> References: <20151112084546.GH1147@redhat.com> Message-ID: I recall that original message about the packaging before RHEL 7.2 and how few of us expressed interest. I believe I did respond to the positive that I could use these packages, but I certainly understand additional effort. I just hate to be waiting on RH's cycle to get updates to one of the pieces of my infrastructure where features are in-demand and getting added more often. I prefer my base server OS's to stay as stable as possible, but FreeIPA is an exception for me. In any case, I appreciate the effort and the response. Just so that I'm clear, this basically means that we should wait until the RHEL 7.2 release (and the following CentOS 7.2 release) before this will generally available? I want to make sure I pay attention to that as it gets released. Thanks, Chris On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy wrote: > On Wed, 11 Nov 2015, Christopher Young wrote: >> >> Do we know what the status of getting these packages prepped and into the >> mainstream repos (like EPEL, I suppose)? >> >> I'm just curious as I try and keep my repos minimal on servers (for >> obvious >> reasons), but I would really like to begin testing/using the functionality >> in 4.2. > > I believe EPEL's policy prevents you from packaging software which > exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is > already published as part of RHEL 7.2 beta in September. > > I want to remind that during this summer I ran few queries here > (freeipa-users@) and elsewhere to solicit opinions whether people want > to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2 > release. Very few responses came back and there wasn't any convincing > feedback that would have justified additional effort to make the > repository and maintenance reasonable. > > https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html > > -- > / Alexander Bokovoy From jbaird at follett.com Fri Nov 20 03:10:37 2015 From: jbaird at follett.com (Baird, Josh) Date: Fri, 20 Nov 2015 03:10:37 +0000 Subject: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1 In-Reply-To: References: <20151112084546.GH1147@redhat.com>, Message-ID: <60B9E13F-168B-4B25-AC18-073468AAF479@follett.com> RHEL 7.2 went GA today. > On Nov 19, 2015, at 7:59 PM, Christopher Young wrote: > > I recall that original message about the packaging before RHEL 7.2 and > how few of us expressed interest. I believe I did respond to the > positive that I could use these packages, but I certainly understand > additional effort. I just hate to be waiting on RH's cycle to get > updates to one of the pieces of my infrastructure where features are > in-demand and getting added more often. I prefer my base server OS's > to stay as stable as possible, but FreeIPA is an exception for me. In > any case, I appreciate the effort and the response. > > Just so that I'm clear, this basically means that we should wait until > the RHEL 7.2 release (and the following CentOS 7.2 release) before > this will generally available? I want to make sure I pay attention to > that as it gets released. > > Thanks, > > Chris > >> On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy wrote: >>> On Wed, 11 Nov 2015, Christopher Young wrote: >>> >>> Do we know what the status of getting these packages prepped and into the >>> mainstream repos (like EPEL, I suppose)? >>> >>> I'm just curious as I try and keep my repos minimal on servers (for >>> obvious >>> reasons), but I would really like to begin testing/using the functionality >>> in 4.2. >> >> I believe EPEL's policy prevents you from packaging software which >> exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is >> already published as part of RHEL 7.2 beta in September. >> >> I want to remind that during this summer I ran few queries here >> (freeipa-users@) and elsewhere to solicit opinions whether people want >> to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2 >> release. Very few responses came back and there wasn't any convincing >> feedback that would have justified additional effort to make the >> repository and maintenance reasonable. >> >> https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html >> >> -- >> / 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 From xuezhiy at gmail.com Fri Nov 20 08:02:16 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Fri, 20 Nov 2015 16:02:16 +0800 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: <564DF498.40209@redhat.com> References: <56494C60.7040709@redhat.com> <564DF498.40209@redhat.com> Message-ID: The problem still exist after update from 4.1 to 4.2.3. Rob, how to check the missed manage entry? 2015-11-20 0:11 GMT+08:00 Rob Crittenden : > zhiyong xue wrote: > > Rob, where can I get more error information beside the log? > > [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: > > failed to delete managed entry > > (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) > > I can still only assume what you're doing: manually adding the entries > directly by LDAP. To do this you need to follow IPA conventions, or use > the new user lifecycle framework added in 4.2. > > I'm guessing it can't delete the managed entry because either it doesn't > exist or it is missing an objectclass/attribute marking it as managed. > > rob > > > > > 2015-11-16 13:43 GMT+08:00 zhiyong xue > >: > > > > I am using IPA 4.1 in CenOS7. And I can login to system after "id > > syncopex5", maybe it's cache problem. > > > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden > >: > > > > zhiyong xue wrote: > > > We integrated the Apache Syncope server with FreeIPA server. > So user can > > > self register ID from Apache Syncope then synchronize to > FreeIPA. The > > > problems are: > > > *1) User created from Apache Syncope can't login to linux. The > > user > > > created from FreeIPA web gui works well.* > > > > For login issues see > > https://fedorahosted.org/sssd/wiki/Troubleshooting > > This is unlikely to fix things but it will help with later > > debugging. > > > > This likely revolves around how you are creating these accounts. > > We'll > > need information on what you're doing. The more details the > better. > > > > > *2) The user also can't be deleted from web UI and CLI. It said > > > "syncopex5: user not found".* > > > > Again, you probably aren't creating the users correctly. > > > > I can only assume that you are creating the users directly via > > an LDAP > > add. This is working around the IPA framework which does > > additional work. > > > > Knowing what version of IPA this is would help too. > > > > You'll probably also want to read this: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This > > is in > > IPA 4.2. > > > > rob > > rob > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 20 09:31:48 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Nov 2015 10:31:48 +0100 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: References: Message-ID: <564EE884.6060909@redhat.com> On 11/19/2015 11:03 PM, Ash Alam wrote: > Hello All > > I am looking for some advice on upgrading. Currently our FreeIPA servers are > 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This upgrade path > is not possible per IPA documentation. Minimum version required is 3.3.x. I > have also found that cenos6 does not provide anything past 3.0.0. And it won't. There are no plans in updating FreeIPA version in RHEL/CentOS-6.x, we encourage people who want the new features to migrate to RHEL-7.x: http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc If you want to wait on CentOS-7.2, it should be in works now: http://seven.centos.org/2015/11/rhel-7-2-released-today/ > One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 on centos7. > This is harder since centos does not provide this. The other issue is if > 3.0/3.3 client will be supported with 4.2.3 server. The right way is to migrate via creating replicas in RHEL/CentOS-7.x and slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the links above. From mkosek at redhat.com Fri Nov 20 09:44:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Nov 2015 10:44:39 +0100 Subject: [Freeipa-users] FreeIPA 4.2 released in RHEL-7.2! Message-ID: <564EEB87.7080805@redhat.com> Hello, As some of you noticed already, RHEL-7.2 with FreeIPA rebased to version 4.2 was released yesterday! Let me just paste couple information sources if you want to know more: RHEL respective release notes chapter: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.2_Release_Notes/authentication_and_interoperability.html Knowledge Base with brief summary of new features https://access.redhat.com/solutions/1986213 Related documentation books: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/index.html Also, CentOS project already announced that CentOS-7.2 is in works: http://seven.centos.org/2015/11/rhel-7-2-released-today/ Enjoy! -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Fri Nov 20 09:45:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Nov 2015 10:45:32 +0100 Subject: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1 In-Reply-To: <60B9E13F-168B-4B25-AC18-073468AAF479@follett.com> References: <20151112084546.GH1147@redhat.com> <60B9E13F-168B-4B25-AC18-073468AAF479@follett.com> Message-ID: <564EEBBC.1050504@redhat.com> On 11/20/2015 04:10 AM, Baird, Josh wrote: > RHEL 7.2 went GA today. Surprise! I posted more information to new thread: https://www.redhat.com/archives/freeipa-users/2015-November/msg00309.html > >> On Nov 19, 2015, at 7:59 PM, Christopher Young wrote: >> >> I recall that original message about the packaging before RHEL 7.2 and >> how few of us expressed interest. I believe I did respond to the >> positive that I could use these packages, but I certainly understand >> additional effort. I just hate to be waiting on RH's cycle to get >> updates to one of the pieces of my infrastructure where features are >> in-demand and getting added more often. I prefer my base server OS's >> to stay as stable as possible, but FreeIPA is an exception for me. In >> any case, I appreciate the effort and the response. >> >> Just so that I'm clear, this basically means that we should wait until >> the RHEL 7.2 release (and the following CentOS 7.2 release) before >> this will generally available? I want to make sure I pay attention to >> that as it gets released. >> >> Thanks, >> >> Chris >> >>> On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy wrote: >>>> On Wed, 11 Nov 2015, Christopher Young wrote: >>>> >>>> Do we know what the status of getting these packages prepped and into the >>>> mainstream repos (like EPEL, I suppose)? >>>> >>>> I'm just curious as I try and keep my repos minimal on servers (for >>>> obvious >>>> reasons), but I would really like to begin testing/using the functionality >>>> in 4.2. >>> >>> I believe EPEL's policy prevents you from packaging software which >>> exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is >>> already published as part of RHEL 7.2 beta in September. >>> >>> I want to remind that during this summer I ran few queries here >>> (freeipa-users@) and elsewhere to solicit opinions whether people want >>> to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2 >>> release. Very few responses came back and there wasn't any convincing >>> feedback that would have justified additional effort to make the >>> repository and maintenance reasonable. >>> >>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html >>> >>> -- >>> / 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 > From tainsworth at vsi-corp.com Fri Nov 20 12:50:21 2015 From: tainsworth at vsi-corp.com (Ainsworth, Thomas) Date: Fri, 20 Nov 2015 07:50:21 -0500 Subject: [Freeipa-users] user question Message-ID: Question: How can you set the password policy to require at least four (4) new characters when the user is setting their password? Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Nov 20 13:58:13 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Nov 2015 08:58:13 -0500 Subject: [Freeipa-users] user question In-Reply-To: References: Message-ID: <564F26F5.4050000@redhat.com> Ainsworth, Thomas wrote: > Question: > > How can you set the password policy to require at least four (4) new > characters when the user is setting their password? I assume you mean 4 new characters as compared to the current password? I don't know of a way to do that. I don't believe the current cleartext password is always available to do such a comparison. rob From rcritten at redhat.com Fri Nov 20 14:02:35 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Nov 2015 09:02:35 -0500 Subject: [Freeipa-users] FreeIPA user can't login to linux. In-Reply-To: References: <56494C60.7040709@redhat.com> <564DF498.40209@redhat.com> Message-ID: <564F27FB.2020007@redhat.com> zhiyong xue wrote: > The problem still exist after update from 4.1 to 4.2.3. Because the problem is not in IPA, it is in how you are manually adding entries. Since you are now running 4.2 I'd suggest you look into using staged users, http://www.freeipa.org/page/V4/User_Life-Cycle_Management > Rob, how to check the missed manage entry? A managed group needs the attribute mepManagedBy with a value of the dn that is managing it and the objectclass mepManagedEntry. rob > > 2015-11-20 0:11 GMT+08:00 Rob Crittenden >: > > zhiyong xue wrote: > > Rob, where can I get more error information beside the log? > > [16/Nov/2015:02:52:59 +0000] managed-entries-plugin - mep_del_post_op: > > failed to delete managed entry > > (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32) > > I can still only assume what you're doing: manually adding the entries > directly by LDAP. To do this you need to follow IPA conventions, or use > the new user lifecycle framework added in 4.2. > > I'm guessing it can't delete the managed entry because either it doesn't > exist or it is missing an objectclass/attribute marking it as managed. > > rob > > > > > 2015-11-16 13:43 GMT+08:00 zhiyong xue > > >>: > > > > I am using IPA 4.1 in CenOS7. And I can login to system after "id > > syncopex5", maybe it's cache problem. > > > > 2015-11-16 11:24 GMT+08:00 Rob Crittenden > > >>: > > > > zhiyong xue wrote: > > > We integrated the Apache Syncope server with FreeIPA > server. So user can > > > self register ID from Apache Syncope then synchronize to > FreeIPA. The > > > problems are: > > > *1) User created from Apache Syncope can't login to > linux. The > > user > > > created from FreeIPA web gui works well.* > > > > For login issues see > > https://fedorahosted.org/sssd/wiki/Troubleshooting > > This is unlikely to fix things but it will help with later > > debugging. > > > > This likely revolves around how you are creating these > accounts. > > We'll > > need information on what you're doing. The more details > the better. > > > > > *2) The user also can't be deleted from web UI and CLI. > It said > > > "syncopex5: user not found".* > > > > Again, you probably aren't creating the users correctly. > > > > I can only assume that you are creating the users directly via > > an LDAP > > add. This is working around the IPA framework which does > > additional work. > > > > Knowing what version of IPA this is would help too. > > > > You'll probably also want to read this: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > . This > > is in > > IPA 4.2. > > > > rob > > rob > > > > > > > > From aalam at paperlesspost.com Fri Nov 20 15:08:13 2015 From: aalam at paperlesspost.com (Ash Alam) Date: Fri, 20 Nov 2015 10:08:13 -0500 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: <564EE884.6060909@redhat.com> References: <564EE884.6060909@redhat.com> Message-ID: Most of the clients in my env are centos 6.6 with ipa 3.0.0 client installed. I if bring up a replica on centos 7.2 with ipa 4.2.3 server and then start phasing out the older 3.0.0 servers. Will the client that are still running the older client software still work? On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek wrote: > On 11/19/2015 11:03 PM, Ash Alam wrote: > >> Hello All >> >> I am looking for some advice on upgrading. Currently our FreeIPA servers >> are >> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This upgrade >> path >> is not possible per IPA documentation. Minimum version required is 3.3.x. >> I >> have also found that cenos6 does not provide anything past 3.0.0. >> > > And it won't. There are no plans in updating FreeIPA version in > RHEL/CentOS-6.x, we encourage people who want the new features to migrate > to RHEL-7.x: > > > http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc > > If you want to wait on CentOS-7.2, it should be in works now: > http://seven.centos.org/2015/11/rhel-7-2-released-today/ > > One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 on centos7. >> This is harder since centos does not provide this. The other issue is if >> 3.0/3.3 client will be supported with 4.2.3 server. >> > > The right way is to migrate via creating replicas in RHEL/CentOS-7.x and > slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the links > above. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Nov 20 15:19:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 16:19:32 +0100 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: References: <564EE884.6060909@redhat.com> Message-ID: <564F3A04.3060702@redhat.com> On 11/20/2015 04:08 PM, Ash Alam wrote: > Most of the clients in my env are centos 6.6 with ipa 3.0.0 client > installed. I if bring up a replica on centos 7.2 with ipa 4.2.3 server > and then start phasing out the older 3.0.0 servers. Will the client that > are still running the older client software still work? > Yes older clients should be able to talk to newer masters. > On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek > wrote: > > On 11/19/2015 11:03 PM, Ash Alam wrote: > > Hello All > > I am looking for some advice on upgrading. Currently our FreeIPA > servers are > 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This > upgrade path > is not possible per IPA documentation. Minimum version required > is 3.3.x. I > have also found that cenos6 does not provide anything past 3.0.0. > > > And it won't. There are no plans in updating FreeIPA version in > RHEL/CentOS-6.x, we encourage people who want the new features to > migrate to RHEL-7.x: > > http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc > > If you want to wait on CentOS-7.2, it should be in works now: > http://seven.centos.org/2015/11/rhel-7-2-released-today/ > > One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 > on centos7. > This is harder since centos does not provide this. The other > issue is if > 3.0/3.3 client will be supported with 4.2.3 server. > > > The right way is to migrate via creating replicas in RHEL/CentOS-7.x > and slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the > links above. > > > > -- Martin^3 Babinsky From karl.forner at gmail.com Fri Nov 20 15:47:25 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 20 Nov 2015 16:47:25 +0100 Subject: [Freeipa-users] freeipa harware appliance Message-ID: Hello, Could you recommend me a mini appliance/server to use as a freeIPA server ? I guess the main points are an ethernet port, minimal consumption, robustness. Thanks, Karl Forner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 20 16:13:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Nov 2015 17:13:47 +0100 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: References: <564EE884.6060909@redhat.com> Message-ID: <564F46BB.8060906@redhat.com> On 11/20/2015 04:08 PM, Ash Alam wrote: > Most of the clients in my env are centos 6.6 with ipa 3.0.0 client installed. I > if bring up a replica on centos 7.2 with ipa 4.2.3 server and then start > phasing out the older 3.0.0 servers. Will the client that are still running the > older client software still work? It should, yes. It is expected that there are RHEL/CentOS-6 clients with RHEL-7 FreeIPA servers. The older clients just won't be able to use the newest features. > > On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek > wrote: > > On 11/19/2015 11:03 PM, Ash Alam wrote: > > Hello All > > I am looking for some advice on upgrading. Currently our FreeIPA > servers are > 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This > upgrade path > is not possible per IPA documentation. Minimum version required is 3.3.x. I > have also found that cenos6 does not provide anything past 3.0.0. > > > And it won't. There are no plans in updating FreeIPA version in > RHEL/CentOS-6.x, we encourage people who want the new features to migrate > to RHEL-7.x: > > http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc > > If you want to wait on CentOS-7.2, it should be in works now: > http://seven.centos.org/2015/11/rhel-7-2-released-today/ > > One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 on centos7. > This is harder since centos does not provide this. The other issue is if > 3.0/3.3 client will be supported with 4.2.3 server. > > > The right way is to migrate via creating replicas in RHEL/CentOS-7.x and > slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the links above. > > From karl.forner at gmail.com Fri Nov 20 15:44:38 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 20 Nov 2015 16:44:38 +0100 Subject: [Freeipa-users] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker) Message-ID: Hello, My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1. The freeipa server runs inside a docker (an adelton/freeipa-server), and the docker host pretends to be the freeIPA server by forwarding the appropriate ports. This works very fine. But when I reboot my server (which is in a locked server room. r), I struggle to connect to it. I'm unable to connect using ssh onto it, using any kind of local or freeIPA accounts onto it. The DNS server (provided by freeIPA) works kine though (i.e. nslookup server server works). Fortunately, I have the monit web app running on the server that allows to restart the ssh service. After restarting ssh remotely. I am now able to connect to the server. It seems that all works fine again once I restart sssd on the server. I know this is a pretty complex setup, but do you have hints that could help me have a usable server after reboot ? Thanks, Karl Forner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Nov 20 17:29:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 18:29:18 +0100 Subject: [Freeipa-users] freeipa harware appliance In-Reply-To: References: Message-ID: <564F586E.3030505@redhat.com> On 20.11.2015 16:47, Karl Forner wrote: > Hello, > > Could you recommend me a mini appliance/server to use as a freeIPA > server ? > I guess the main points are an ethernet port, minimal consumption, > robustness. > > Thanks, > Karl Forner > > Hello, I would say that minimal amount of RAM is 2GB with IPA 4.2, of course amount of resources depends on many things. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Preparing_for_an_IPA_Installation-Hardware_Requirements.html Disk space at least 500MB for basic installation + baseOS + stored data I do not know if IPA is limited by a CPU in somehow, but with very slow CPU you may need to increase timeouts (I saw the posts on this lists that it is possible to run IPA on raspberry pi with increased timeouts) Maybe would be better if you write what do you need this minimal configuration for and how many clients, users and connections should IPA handle. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Fri Nov 20 17:37:42 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 20 Nov 2015 18:37:42 +0100 Subject: [Freeipa-users] freeipa harware appliance In-Reply-To: <564F586E.3030505@redhat.com> References: <564F586E.3030505@redhat.com> Message-ID: Thanks Martin. My expected numbers: users ~ 50 max, concurrent clients/sessions < 20, hosts < 20. I was thinking about a server with an old intel cpu, 4Gb RAM and smal HDD or USB key-based storage + an ethernet port. I have no idea if it is a common use in IT to run such (critical) application on its own dedicated appliance. On Fri, Nov 20, 2015 at 6:29 PM, Martin Basti wrote: > > > On 20.11.2015 16:47, Karl Forner wrote: > > Hello, > > Could you recommend me a mini appliance/server to use as a freeIPA server > ? > I guess the main points are an ethernet port, minimal consumption, > robustness. > > Thanks, > Karl Forner > > > Hello, > > I would say that minimal amount of RAM is 2GB with IPA 4.2, of course > amount of resources depends on many things. > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Preparing_for_an_IPA_Installation-Hardware_Requirements.html > > Disk space at least 500MB for basic installation + baseOS + stored data > > I do not know if IPA is limited by a CPU in somehow, but with very slow > CPU you may need to increase timeouts (I saw the posts on this lists that > it is possible to run IPA on raspberry pi with increased timeouts) > > Maybe would be better if you write what do you need this minimal > configuration for and how many clients, users and connections should IPA > handle. > > Martin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstormshak at cccis.com Fri Nov 20 18:07:08 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Fri, 20 Nov 2015 18:07:08 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> Message-ID: Rob - Thank you for the suggestions as I finally have them implemented. However, the twist to this saga, is that it only works when I bind to LDAP as "anonymous" vs. setting an actual "binddn" and "bindpw". I truly do not want to keep it this way. With that being said, may I ask what should be the proper binddn account to use so that auth and sudo will work? Once again, thank you for the help getting me further down the configuration trail. !! -----Original Message----- From: Jeffrey Stormshak Sent: Tuesday, November 17, 2015 10:49 AM To: Jeffrey Stormshak; Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com Subject: RE: [Freeipa-users] Oracle Linux 5.5 - Legacy Question I meant "did" forget. Silly typo on my behalf... -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak Sent: Tuesday, November 17, 2015 10:44 AM To: Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Thanks Rob! Sorry, I didn't forget to mention what was the message. It basically stated the message listed below. Sorry, user plmoss may not run sudo on client_server Let me try your suggestions and see if that helps lead me down the right path. Once again, thanks for this feedback. Oh how I miss using the "ipa-client" I used on all of my higher Linux versions. Talk about saving time cycles and deployment timeframes. Oh well. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 17, 2015 9:51 AM To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Jeffrey Stormshak wrote: > Thank you for the response. If I may, can you expand more on the sudoers response? > > More details from my configuration ... > The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. > > uri ldap://ldap-server-name/ > sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn > uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM > bindpw secret_pass > bind_timelimit 5 > timelimit 15 > > In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? It's hard to know what to recommend since you haven't said what isn't working. Your nssswitch.conf should have: sudoers: files ldap You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. You almost certainly want to use TLS here: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes You also need your nisdomainname set to your domain to do group or host-based sudo. You also need to add this to your sssd.conf: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com Stick it after ipa_server in the config file. Use sudo -l to test. rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Tuesday, November 17, 2015 2:56 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: >> Greetings --- >> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... >> >> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! > > Not sure about TLS but sudoers should be managed with their ldap > config (there's no sssd, hence to sssd sudo integration..) > > -- > 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 From rob.verduijn at gmail.com Fri Nov 20 19:16:42 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 20 Nov 2015 20:16:42 +0100 Subject: [Freeipa-users] service account for ovirt In-Reply-To: <564CD2E1.8040308@redhat.com> References: <564C9086.901@redhat.com> <564CD2E1.8040308@redhat.com> Message-ID: Hello, I've tested the solution you suggested it doesnt work I think ovirt-engine looks for the other users in the same context as the bind user, it will ofcourse find not many there, I can't get the seconf option with the keytab to work. So I'm stuck with the full blown user account for this. Here's what I did : The ovirt os is centos 6 x86_64 All the latest patches have been applied. It can be a member of the freeipa domain but this is not required for the ovirt-freeipa authentication to work. personally I think its nice to have the ovirt machine under freeipa supervision as wel. the freeipa os is centos7 x*6_64 All the latest patches have been applied. The ovirt environment is configured, up and running. There are two ways of single sign on for ovirt. see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html This howto is for the first option you require a search account in the freeipa domain. add a user account to the freeipa domain login with that account so it asks you to set a new password for it then reset the experation date for the password to somewhere in the far future with the procedure below # # Add the search account for ovirt to the freeipa domain. # # executed these commands on the freeipa server as root. # # first set the variables export SUFFIX='dc=example,dc=com' export OVIRT_SERVER=ovirt.example.com export FREEIPA_DOMAIN=EXAMPLE.COM export USERNAME=ovirt export YOUR_PASSWORD='top_secret_random_very_long_password' # create an ldif file cat > resetexperation.ldif << EOF dn: uid=$USERNAME,cn=users,cn=accounts,$SUFFIX changetype: modify replace: krbpasswordexpiration krbpasswordexpiration: 20380119031407Z EOF # apply the ldif file # the password requested is the directory admin password, this is NOT the same account as the freeipa admin ldapmodify -x -D "cn=directory manager" -W -vv -f resetexperation.ldif # for the second option also : # add the service for http to freeipa kinit admin ipa service-add HTTP/$OVIRT_SERVER@$FREEIPA_DOMAIN # # The following commands are executed as root on the ovirt-engine machine. # This is the example that allows single sign on from the portal to the vm's # Assuming the forementioned bindaccount exists in the freeipa domain # # # first install the required package : # yum install -y ovirt-engine-extension-aaa-ldap # # create the ovirt configuration files # examples can be found here : # /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. # mkdir /etc/ovirt-engine/aaa mkdir /etc/ovirt-engine/extenstions.d # # set the vars again ( exports do not work between vm's) # export SUFFIX='dc=example,dc=com' export YOUR_PASSWORD='top_secret_random_very_long_password' export FREEIPA_SERVER=freeipa.example.com export PROFILE_NAME=profile1 # # create the config files # cat > /etc/ovirt-engine/aaa/$PROFILE_NAME.properties << EOF include = vars.server = $FREEIPA_SERVER vars.user = uid=ovirt,cn=users,cn=accounts,$SUFFIX vars.password = $YOUR_PASSWORD pool.default.serverset.single.server = \${global:vars.server} pool.default.auth.simple.bindDN = \${global:vars.user} pool.default.auth.simple.password = \${global:vars.password} EOF cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authz.properties << EOF ovirt.engine.extension.name = $PROFILE_NAME-authz ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/$PROFILE_NAME.properties EOF cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties << EOF ovirt.engine.extension.name = $PROFILE_NAME-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = $PROFILE_NAME ovirt.engine.aaa.authn.authz.plugin = $PROFILE_NAME-authz config.profile.file.1 = ../aaa/$PROFILE_NAME.properties EOF # # change owner and permissions of the profile file # chown ovirt:ovirt /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties chmod 400 /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties # # restart the ovirt engine # service ovirt-engine restart # # done you can now add freeipa users to the rhevm portal in the users menu # after the users have been added you can assign permissions for them on the vm's # Cheers Rob Verduijn 2015-11-18 20:34 GMT+01:00 Martin Kosek : > On 11/18/2015 04:27 PM, Rob Verduijn wrote: >> >> 2015-11-18 15:51 GMT+01:00 Martin Kosek : >>> >>> On 11/18/2015 08:23 AM, Rob Verduijn wrote: >>>> >>>> Hello all, >>>> >>>> I've read a lot regarding service accounts on this mailinglist in the >>>> past. >>>> But it's rather unclear to me what is the current preffered method to >>>> create a service account for a service running on a different machine. >>>> >>>> In this case it would be a service account for ovirt so that freeipa >>>> users can authenticate in the ovirt portal using their freeipa >>>> credentials. >>> >>> >>> It sounds like that you do not want system user account, but you are OK >>> with >>> service account so that you can get a keytab for your oVirt instance. In >>> that >>> case, simple >>> >>> $ ipa service-add HTTP/frontend.ovirt.test >>> and >>> $ ipa-getkeytab ... >>> should be enough, right? >>> >>> Maybe I just do not understand the use case. >>> >>>> I could ofcourse create an account and then apply a ldf to set its >>>> password expiration to the next millennium to make sure the password >>>> does not expire. >>>> >>>> Anybody who has a good suggestion on how to deal with this ? >>>> >>>> Cheers >>>> Rob Verduijn >>>> >>> >> >> >> >> Hello, >> >> I think some more context should clear this up a bit. >> >> according to the rhev administrator guide: (ovirt referes to rhev manuals >> a lot) >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html >> >> It talks about two options as a single sign on solution. >> >> On have the single sign on work for the portal, but then it won't work >> for the vm's. >> ( something about not being able to pass a password since the portal >> won't have one to pass ) >> >> Or have the single sign on work for the vm's but than you have to sign >> in to the portal so it can pass on your credentials to the vm's. >> >> I guess there is some interesting technical challenge to deal with to >> merge those two cases. >> >> The first option requires privileges to browse the freeipa directory >> to look for user accounts. >> I do not know if that can be solved with something as simple as a >> keytab and a pricipal. >> >> My current working solution is an account with a very long password >> experation time in the freeipa directory >> ( a random 32 character/number password is being used for this ) >> >> However something tells me that there is a more elegant solution. >> And I was wondering if anyone knows one. > > > Reading the HowTo, I think using normal FreeIPA POSIX user with password > policy, uid, home and all the rings and bells may be an over kill. You could > replica what is done with sudo system user for binding to LDAP for example: > > # ldapmodify -D "cn=Directory Manager" -x -W > dn: uid=ovirt,cn=sysaccounts,cn=etc,$SUFFIX > changetype: add > objectclass: account > objectclass: simplesecurityobject > uid: sudo > userPassword: $YOUR_PASSWORD > passwordExpirationTime: 20380119031407Z > nsIdleTimeout: 0 > > and use that as oVirt BIND user. As for keytab, you just would not use > kadmin, but rather add the service object with "service-add" and get the > keytab with "ipa-getkeytab". > > Other than that, the HowTo was mostly about oVirt side of configuration. > > If you succeed, it would nice to record your steps specific to FreeIPA in a > HowTo article on FreeIPA :-) > > http://www.freeipa.org/page/HowTos > http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki > > Martin From rcritten at redhat.com Fri Nov 20 19:42:03 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Nov 2015 14:42:03 -0500 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> Message-ID: <564F778B.5050106@redhat.com> Jeffrey Stormshak wrote: > Rob - > Thank you for the suggestions as I finally have them implemented. However, the twist to this saga, is that it only works when I bind to LDAP as "anonymous" vs. setting an actual "binddn" and "bindpw". I truly do not want to keep it this way. With that being said, may I ask what should be the proper binddn account to use so that auth and sudo will work? I'm not sure how it works at all anonymously as it should return nothing in that case. IIRC a sudo system account user is pre-created you just need to set the password: $ ldappasswd -x -S -W -h ipaserver.ipadocs.org -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com rob > > Once again, thank you for the help getting me further down the configuration trail. !! > > -----Original Message----- > From: Jeffrey Stormshak > Sent: Tuesday, November 17, 2015 10:49 AM > To: Jeffrey Stormshak; Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com > Subject: RE: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > I meant "did" forget. Silly typo on my behalf... > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak > Sent: Tuesday, November 17, 2015 10:44 AM > To: Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > Thanks Rob! Sorry, I didn't forget to mention what was the message. It basically stated the message listed below. > > Sorry, user plmoss may not run sudo on client_server > > Let me try your suggestions and see if that helps lead me down the right path. Once again, thanks for this feedback. Oh how I miss using the "ipa-client" I used on all of my higher Linux versions. Talk about saving time cycles and deployment timeframes. Oh well. > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, November 17, 2015 9:51 AM > To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > Jeffrey Stormshak wrote: >> Thank you for the response. If I may, can you expand more on the sudoers response? >> >> More details from my configuration ... >> The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. >> >> uri ldap://ldap-server-name/ >> sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn >> uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM >> bindpw secret_pass >> bind_timelimit 5 >> timelimit 15 >> >> In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? > > It's hard to know what to recommend since you haven't said what isn't working. > > Your nssswitch.conf should have: > > sudoers: files ldap > > You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. > > You almost certainly want to use TLS here: > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > You also need your nisdomainname set to your domain to do group or host-based sudo. > > You also need to add this to your sssd.conf: > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > Stick it after ipa_server in the config file. > > Use sudo -l to test. > > rob >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek >> Sent: Tuesday, November 17, 2015 2:56 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question >> >> On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: >>> Greetings --- >>> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... >>> >>> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! >> >> Not sure about TLS but sudoers should be managed with their ldap >> config (there's no sssd, hence to sssd sudo integration..) >> >> -- >> 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 > From holosian at gmail.com Fri Nov 20 21:24:39 2015 From: holosian at gmail.com (holo) Date: Fri, 20 Nov 2015 22:24:39 +0100 Subject: [Freeipa-users] Squid authentication in FreeIPA Message-ID: <1448054679.18336.8.camel@gmail.com> Hello I configured Squid to use kerberos authentication according to that howto:?http://www.freeipa.org/page/Squid_Integration_with_FreeIPA_using _Single_Sign_On?but I'm not getting any popup when im trying to use proxy, instead I'm just getting information that I'm not authenticated. Anyone is using FreeIPA in such configuration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tainsworth at vsi-corp.com Thu Nov 19 12:42:42 2015 From: tainsworth at vsi-corp.com (Ainsworth, Thomas) Date: Thu, 19 Nov 2015 07:42:42 -0500 Subject: [Freeipa-users] Password Policy Inquiry Message-ID: Greetings, How in FreeIPA would one set the password policy equivalent to the* pam.d* paramater *difok*? This paramater ensures the new password has at least N number of characters different than the current password. Thanks in advance, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From holosian at gmail.com Fri Nov 20 21:47:25 2015 From: holosian at gmail.com (holo) Date: Fri, 20 Nov 2015 22:47:25 +0100 Subject: [Freeipa-users] LDAP creditentials for Squid Message-ID: <1448056045.18336.12.camel@gmail.com> Hello How can i find FreeIPA ldap creditentials? I want to try to configure Squid in similar way like it is described here for ejabberd: http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDA P_Group_memberships //holo -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Fri Nov 20 21:41:35 2015 From: loris at lgs.com.ve (Loris Santamaria) Date: Fri, 20 Nov 2015 17:11:35 -0430 Subject: [Freeipa-users] Squid authentication in FreeIPA In-Reply-To: <1448054679.18336.8.camel@gmail.com> References: <1448054679.18336.8.camel@gmail.com> Message-ID: <1448055695.3784.34.camel@lgs.com.ve> El vie, 20-11-2015 a las 22:24 +0100, holo escribi?: > Hello > > I configured Squid to use kerberos authentication according to that > howto:?http://www.freeipa.org/page/Squid_Integration_with_FreeIPA_usi > ng_Single_Sign_On?but I'm not getting any popup when im trying to use > proxy, instead I'm just getting information that I'm not > authenticated. > > Anyone is using FreeIPA in such configuration? Yes and it works perfectly.? First check the basic stuff: the pc accessing squid should be part of the ipa domain or a trusted domain, the browser should be configured to access squid by its full name (accessing by IP won't work), browser must support negotiate auth, client and server clocks must be in sync. If everything seems ok, restart squid, try connection from a client, and check for any error messages in squid's cache.log file Best regards > -- > 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 -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5693 bytes Desc: not available URL: From tainsworth at vsi-corp.com Fri Nov 20 22:31:39 2015 From: tainsworth at vsi-corp.com (Ainsworth, Thomas) Date: Fri, 20 Nov 2015 17:31:39 -0500 Subject: [Freeipa-users] freeipa harware appliance In-Reply-To: References: <564F586E.3030505@redhat.com> Message-ID: You could buy a couple of NUC's (or equivalent) with a SSD (or not) and run a replica. Extremely small footprint. IPA itself is light weight; that is part of the beauty of it. On Fri, Nov 20, 2015 at 12:37 PM, Karl Forner wrote: > Thanks Martin. > My expected numbers: users ~ 50 max, concurrent clients/sessions < 20, > hosts < 20. > I was thinking about a server with an old intel cpu, 4Gb RAM and smal HDD > or USB key-based storage + an ethernet port. > I have no idea if it is a common use in IT to run such (critical) > application on its own dedicated appliance. > > > > On Fri, Nov 20, 2015 at 6:29 PM, Martin Basti wrote: > >> >> >> On 20.11.2015 16:47, Karl Forner wrote: >> >> Hello, >> >> Could you recommend me a mini appliance/server to use as a freeIPA server >> ? >> I guess the main points are an ethernet port, minimal consumption, >> robustness. >> >> Thanks, >> Karl Forner >> >> >> Hello, >> >> I would say that minimal amount of RAM is 2GB with IPA 4.2, of course >> amount of resources depends on many things. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Preparing_for_an_IPA_Installation-Hardware_Requirements.html >> >> Disk space at least 500MB for basic installation + baseOS + stored data >> >> I do not know if IPA is limited by a CPU in somehow, but with very slow >> CPU you may need to increase timeouts (I saw the posts on this lists that >> it is possible to run IPA on raspberry pi with increased timeouts) >> >> Maybe would be better if you write what do you need this minimal >> configuration for and how many clients, users and connections should IPA >> handle. >> >> Martin >> >> >> > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Nov 20 23:12:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Nov 2015 18:12:33 -0500 Subject: [Freeipa-users] Password Policy Inquiry In-Reply-To: References: Message-ID: <564FA8E1.6040502@redhat.com> Ainsworth, Thomas wrote: > Greetings, > > How in FreeIPA would one set the password policy equivalent > to**the*pam.d* paramater *difok*? > This paramater ensures the new password has at least N number of > characters different than > the current password. > https://www.redhat.com/archives/freeipa-users/2015-November/msg00312.html From jstormshak at cccis.com Sat Nov 21 02:21:52 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Sat, 21 Nov 2015 02:21:52 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <564F778B.5050106@redhat.com> References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> Message-ID: Rob - Here?s the test configurations/data when I manipulate the BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux 5.5. I have three questions below that I would like to get your comments on or see what you may recommend on this. I?m seriously perplexed on this as to why its working this way ? Please advise. Thanks! ************************************************************** AUTH successful on login; SUDO fails with the message listed below !! ************************************************************** [mjsmith at chi-infra-idm-client2 ~]$ sudo -l sudo: ldap_sasl_bind_s(): Server is unwilling to perform [sudo] password for mjsmith: Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. ***************************************************** ***************************************************** # grep -iv ?#? /etc/ldap.conf ***************************************************** base dc=linuxcccis,dc=com uri ldap://chi-infra-idm-p1.linuxcccis.com/ binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com bindpw secret_pass timelimit 15 bind_timelimit 5 idle_timelimit 3600 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm pam_password md5 sudoers_base ou=SUDOers,dc=linuxcccis,dc=com ************************************************* User Account AUTH and SUDO works when commenting both the binddn and bindpw fields !! ************************************************* vi /etc/ldap.conf ? Comment these two fields ? #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com #bindpw secret_pass ************************************************ This file unchanged during the above testing !! ************************************************ /etc/sudo-ldap.conf: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com bindpw secret_pass ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://chi-infra-idm-p1.linuxcccis.com sudoers_base ou=SUDOers,dc=linuxcccis,dc=com QUESTIONS: 1) What BINDN account needs to be specified to allow the BINDDN/BINDPW to work for SUDO? 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, but SUDO then fails? 3) If I leave BINDDN/BINDPW blank, what security risks are being introduced by leaving it that way? From: Rob Crittenden > Date: Friday, November 20, 2015 at 1:42 PM To: Jeffrey Stormshak >, Jakub Hrozek >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Jeffrey Stormshak wrote: Rob - Thank you for the suggestions as I finally have them implemented. However, the twist to this saga, is that it only works when I bind to LDAP as "anonymous" vs. setting an actual "binddn" and "bindpw". I truly do not want to keep it this way. With that being said, may I ask what should be the proper binddn account to use so that auth and sudo will work? I'm not sure how it works at all anonymously as it should return nothing in that case. IIRC a sudo system account user is pre-created you just need to set the password: $ ldappasswd -x -S -W -h ipaserver.ipadocs.org -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com rob Once again, thank you for the help getting me further down the configuration trail. !! -----Original Message----- From: Jeffrey Stormshak Sent: Tuesday, November 17, 2015 10:49 AM To: Jeffrey Stormshak; Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com Subject: RE: [Freeipa-users] Oracle Linux 5.5 - Legacy Question I meant "did" forget. Silly typo on my behalf... -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak Sent: Tuesday, November 17, 2015 10:44 AM To: Rob Crittenden; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Thanks Rob! Sorry, I didn't forget to mention what was the message. It basically stated the message listed below. Sorry, user plmoss may not run sudo on client_server Let me try your suggestions and see if that helps lead me down the right path. Once again, thanks for this feedback. Oh how I miss using the "ipa-client" I used on all of my higher Linux versions. Talk about saving time cycles and deployment timeframes. Oh well. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, November 17, 2015 9:51 AM To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Jeffrey Stormshak wrote: Thank you for the response. If I may, can you expand more on the sudoers response? More details from my configuration ... The current setup for me is that all my sudoers rules/commands and groups are defined and stored in the RHEL 7.1 IDM LDAP. When I create the /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on these 5.5 Linux clients. uri ldap://ldap-server-name/ sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM bindpw secret_pass bind_timelimit 5 timelimit 15 In your experience, am I missing some other component? PAM Modules? Reference in the /etc/nsswitch.conf? It's hard to know what to recommend since you haven't said what isn't working. Your nssswitch.conf should have: sudoers: files ldap You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while debugging. You almost certainly want to use TLS here: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes You also need your nisdomainname set to your domain to do group or host-based sudo. You also need to add this to your sssd.conf: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com Stick it after ipa_server in the config file. Use sudo -l to test. rob -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek Sent: Tuesday, November 17, 2015 2:56 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Mon, Nov 16, 2015 at 08:58:37PM +0000, Jeffrey Stormshak wrote: Greetings --- I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great number of Oracle Linux 5.5 servers. Upon research from Oracle (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then upstream. I went ahead and configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. With that history being said ... I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM to these 5.5 clients. Can anyone share some insight or documentation details on how to solve these two problems prior to my mass deployment? Any insight is greatly appreciated. Thanks! Not sure about TLS but sudoers should be managed with their ldap config (there's no sssd, hence to sssd sudo integration..) -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holosian at gmail.com Fri Nov 20 22:21:04 2015 From: holosian at gmail.com (holo) Date: Fri, 20 Nov 2015 23:21:04 +0100 Subject: [Freeipa-users] Squid authentication in FreeIPA In-Reply-To: <1448055695.3784.34.camel@lgs.com.ve> References: <1448054679.18336.8.camel@gmail.com> <1448055695.3784.34.camel@lgs.com.ve> Message-ID: <1448058064.18336.16.camel@gmail.com> Thank you for your reply.? I think i wasnt clear enough. Clients of proxy server are not kerberized. I want to just authenticate them for proxy use in kerberos DB when they are trying to use it (just by popup like in NTLM). Is such thing possible with kerberos? I saw on yt such thing wasa posible with AD. //holo On Fri, 2015-11-20 at 17:11 -0430, Loris Santamaria wrote: > El vie, 20-11-2015 a las 22:24 +0100, holo escribi?: > > Hello > > > > I configured Squid to use kerberos authentication according to that > > howto:?http://www.freeipa.org/page/Squid_Integration_with_FreeIPA_u > > sing_Single_Sign_On?but I'm not getting any popup when im trying to > > use proxy, instead I'm just getting information that I'm not > > authenticated. > > > > Anyone is using FreeIPA in such configuration? > Yes and it works perfectly.? > > First check the basic stuff: the pc accessing squid should be part of > the ipa domain or a trusted domain, the browser should be configured > to access squid by its full name (accessing by IP won't work), > browser must support negotiate auth, client and server clocks must be > in sync. > > If everything seems ok, restart squid, try connection from a client, > and check for any error messages in squid's cache.log file > > Best regards > > > -- > > 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 > -- > Loris Santamaria???linux user #70506???xmpp:loris at lgs.com.ve > Links Global Services, C.A.????????????http://www.lgs.com.ve > Tel: 0286 952.06.87??Cel: 0414 095.00.10??sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Sat Nov 21 05:53:14 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 21 Nov 2015 06:53:14 +0100 Subject: [Freeipa-users] LDAP creditentials for Squid In-Reply-To: <1448056045.18336.12.camel@gmail.com> References: <1448056045.18336.12.camel@gmail.com> Message-ID: hi, On Fri, Nov 20, 2015 at 10:47 PM, holo wrote: > Hello > > How can i find FreeIPA ldap creditentials? I want to try to configure > Squid in similar way like it is described here for ejabberd: > > > http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDAP_Group_memberships > > I do not understand the question. Do you want to user ldap with squid? Then you need to configure an authentication helper in squid. You will find how to do that in the squid wiki: http://wiki.squid-cache.org/ConfigExamples/Authenticate/Ldap And for squid acls dependeing on ldap group membership take a look at the examples here: https://workaround.org/squid-ldap/ If you have trouble configuring squid, then you should ask on the squid mailing list (very active, very helpful). -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Sat Nov 21 05:57:09 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 21 Nov 2015 06:57:09 +0100 Subject: [Freeipa-users] Squid authentication in FreeIPA In-Reply-To: <1448058064.18336.16.camel@gmail.com> References: <1448054679.18336.8.camel@gmail.com> <1448055695.3784.34.camel@lgs.com.ve> <1448058064.18336.16.camel@gmail.com> Message-ID: hi holo, On Fri, Nov 20, 2015 at 11:21 PM, holo wrote: > Thank you for your reply. > > I think i wasnt clear enough. Clients of proxy server are not kerberized. > I want to just authenticate them for proxy use in kerberos DB when they are > trying to use it (just by popup like in NTLM). Is such thing possible with > kerberos? I saw on yt such thing wasa posible with AD. > > //holo > did you ask this question in serverfault as well :-) ? http://serverfault.com/questions/737902/squid-kerberos-authentication-no-popup/737909#737909 If you require ntlm, then you should joing the squid host to an AD realm, I do not think this will work with freeipa because it does not do ntlm as far as I know. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Mon Nov 23 03:44:58 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Sun, 22 Nov 2015 20:44:58 -0700 Subject: [Freeipa-users] web ui runtime error Message-ID: <56528BBA.9050808@cora.nwra.com> Trying to install freeipa-server on Fedora 23. When I try to connect to the web UI from a non-domain EL7 client with firefox I get: Runtime error Web UI got in unrecoverable state during "init" phase Technical details: The operation is insecure. .cache["freeipa/app_container"]/ Hi! I am having trouble with setting up NFSv4 login for users on my IdM network. Normally all users should be able to ssh into the servers using keys, but this happens for only my user (an admin). And when I login and sudo as root, and then su - username, listing the contents of the user's directory, I see everything is owned by nobody:nobody I setup NFSv4 based on the instructions in this blog: http://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ In a nutshell, I setup like this: 1. Added service principals for the nfs server and a few clients with ipa-service-add, on my primary IPA server "ipa service-add nfs/nfs.mydomain.com" "ipa service-add nfs/atestclient.testing.mydomain.com" "ipa service-add nfs/aserver.mydomain.com" 2. Added the auto.home map (In my case, my users use /share, not /home, so I created an auto.share map instead) "ipa automountmap-add default auto.share" 3. Added the auto.share to auto.master "ipa automountkey-add default --key "/share" --info auto.share auto.master " 4. Added the key to the auto.share map ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs.qrios.com:/share/&" auto.share" 5. Created Keytab on the NFS Server as described. "ipa-getkeytab -s ipa1.mydomain.com -p nfs/nfs.mydomain.com -k /etc/krb5.keytab" 6. Told the server to use secure NFS, created the share and started the service. 7. I also added each servers keytab onto it, and ran ipa-client-automount. But now, on each server, I can only login password-less with one account, other accounts demand passwords, and when the user logs in permissions are set to nobody:nobody. My /etc/exports: /share *(rw,sec=sys:krb5:krb5i:krb5p) I see no errors in the nfs server logs, and on the client. I am grateful for any guidance provided. Thank you! From jhrozek at redhat.com Mon Nov 23 07:58:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Nov 2015 08:58:46 +0100 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> Message-ID: <20151123075846.GA12432@hendrix> On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > Rob - > Here?s the test configurations/data when I manipulate the BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux 5.5. I have three questions below that I would like to get your comments on or see what you may recommend on this. I?m seriously perplexed on this as to why its working this way ? Please advise. Thanks! > > ************************************************************** > AUTH successful on login; SUDO fails with the message listed > below !! > ************************************************************** > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > sudo: ldap_sasl_bind_s(): Server is unwilling to perform Looks like the bind didn't finish successfully, can you look into debugging sudo itself? The debugging changed a bit between releases, but The sudo documentation would tell you.. > [sudo] password for mjsmith: > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > ***************************************************** > > ***************************************************** > # grep -iv ?#? /etc/ldap.conf > ***************************************************** > base dc=linuxcccis,dc=com > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > bindpw secret_pass > timelimit 15 > bind_timelimit 5 > idle_timelimit 3600 > nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > pam_password md5 > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > ************************************************* > User Account AUTH and SUDO works when > commenting both the binddn and bindpw fields !! > ************************************************* > vi /etc/ldap.conf ? Comment these two fields ? > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > #bindpw secret_pass > > ************************************************ > This file unchanged during the above testing !! > ************************************************ > /etc/sudo-ldap.conf: > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > bindpw secret_pass > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > bind_timelimit 5 > timelimit 15 > uri ldap://chi-infra-idm-p1.linuxcccis.com > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > QUESTIONS: > 1) What BINDN account needs to be specified to allow the BINDDN/BINDPW to work for SUDO? > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, but SUDO then fails? > 3) If I leave BINDDN/BINDPW blank, what security risks are being introduced by leaving it that way? Anyone on the network can read sudo rules. I guess in theory, the attacker might target accounts who are allowed to run sudo rules as a gateway for getting elevated privileges on the machine.. From mkosek at redhat.com Mon Nov 23 08:02:27 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Nov 2015 09:02:27 +0100 Subject: [Freeipa-users] service account for ovirt In-Reply-To: References: <564C9086.901@redhat.com> <564CD2E1.8040308@redhat.com> Message-ID: <5652C813.10701@redhat.com> On 11/20/2015 08:16 PM, Rob Verduijn wrote: > Hello, > > I've tested the solution you suggested it doesnt work > I think ovirt-engine looks for the other users in the same context as > the bind user, it will ofcourse find not many there, Ah, I see. oVirt apparently expects the users to be only in the users container and not in the system user container. I am thinking this might be something that can be improved, as it would be much easier to do with system user, on the first look. > I can't get the seconf option with the keytab to work. > So I'm stuck with the full blown user account for this. Can you show some error log, why ipa-getkeytab on a service failed? It should just work, if you add appropriate service with service-add and then ask for the keytab with power account. > Here's what I did : > > The ovirt os is centos 6 x86_64 > All the latest patches have been applied. > It can be a member of the freeipa domain but this is not required for > the ovirt-freeipa authentication to work. > personally I think its nice to have the ovirt machine under freeipa > supervision as wel. > > the freeipa os is centos7 x*6_64 > All the latest patches have been applied. > > The ovirt environment is configured, up and running. > > There are two ways of single sign on for ovirt. > see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html > > This howto is for the first option > you require a search account in the freeipa domain. > add a user account to the freeipa domain > login with that account so it asks you to set a new password for it > then reset the experation date for the password to somewhere in the > far future with the procedure below > > # > # Add the search account for ovirt to the freeipa domain. > # > # executed these commands on the freeipa server as root. > # > > # first set the variables > export SUFFIX='dc=example,dc=com' > export OVIRT_SERVER=ovirt.example.com > export FREEIPA_DOMAIN=EXAMPLE.COM > export USERNAME=ovirt > export YOUR_PASSWORD='top_secret_random_very_long_password' > > # create an ldif file > cat > resetexperation.ldif << EOF > dn: uid=$USERNAME,cn=users,cn=accounts,$SUFFIX > changetype: modify > replace: krbpasswordexpiration > krbpasswordexpiration: 20380119031407Z > EOF > > # apply the ldif file > # the password requested is the directory admin password, this is NOT > the same account as the freeipa admin > ldapmodify -x -D "cn=directory manager" -W -vv -f resetexperation.ldif > > # for the second option also : > # add the service for http to freeipa > kinit admin > ipa service-add HTTP/$OVIRT_SERVER@$FREEIPA_DOMAIN > > # > # The following commands are executed as root on the ovirt-engine machine. > # This is the example that allows single sign on from the portal to the vm's > # Assuming the forementioned bindaccount exists in the freeipa domain > # > > # > # first install the required package : > # > > yum install -y ovirt-engine-extension-aaa-ldap > > # > # create the ovirt configuration files > # examples can be found here : > # /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. > # > > mkdir /etc/ovirt-engine/aaa > mkdir /etc/ovirt-engine/extenstions.d > > # > # set the vars again ( exports do not work between vm's) > # > > export SUFFIX='dc=example,dc=com' > export YOUR_PASSWORD='top_secret_random_very_long_password' > export FREEIPA_SERVER=freeipa.example.com > export PROFILE_NAME=profile1 > > # > # create the config files > # > cat > /etc/ovirt-engine/aaa/$PROFILE_NAME.properties << EOF > include = > vars.server = $FREEIPA_SERVER > vars.user = uid=ovirt,cn=users,cn=accounts,$SUFFIX > vars.password = $YOUR_PASSWORD > pool.default.serverset.single.server = \${global:vars.server} > pool.default.auth.simple.bindDN = \${global:vars.user} > pool.default.auth.simple.password = \${global:vars.password} > EOF > > cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authz.properties << EOF > ovirt.engine.extension.name = $PROFILE_NAME-authz > ovirt.engine.extension.bindings.method = jbossmodule > ovirt.engine.extension.binding.jbossmodule.module = > org.ovirt.engine-extensions.aaa.ldap > ovirt.engine.extension.binding.jbossmodule.class = > org.ovirt.engineextensions.aaa.ldap.AuthzExtension > ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz > config.profile.file.1 = ../aaa/$PROFILE_NAME.properties > EOF > > cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties << EOF > ovirt.engine.extension.name = $PROFILE_NAME-authn > ovirt.engine.extension.bindings.method = jbossmodule > ovirt.engine.extension.binding.jbossmodule.module = > org.ovirt.engine-extensions.aaa.ldap > ovirt.engine.extension.binding.jbossmodule.class = > org.ovirt.engineextensions.aaa.ldap.AuthnExtension > ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn > ovirt.engine.aaa.authn.profile.name = $PROFILE_NAME > ovirt.engine.aaa.authn.authz.plugin = $PROFILE_NAME-authz > config.profile.file.1 = ../aaa/$PROFILE_NAME.properties > EOF > > # > # change owner and permissions of the profile file > # > chown ovirt:ovirt /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties > chmod 400 /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties > > # > # restart the ovirt engine > # > service ovirt-engine restart > > # > # done you can now add freeipa users to the rhevm portal in the users menu > # after the users have been added you can assign permissions for them > on the vm's > # > > > Cheers > Rob Verduijn > > 2015-11-18 20:34 GMT+01:00 Martin Kosek : >> On 11/18/2015 04:27 PM, Rob Verduijn wrote: >>> >>> 2015-11-18 15:51 GMT+01:00 Martin Kosek : >>>> >>>> On 11/18/2015 08:23 AM, Rob Verduijn wrote: >>>>> >>>>> Hello all, >>>>> >>>>> I've read a lot regarding service accounts on this mailinglist in the >>>>> past. >>>>> But it's rather unclear to me what is the current preffered method to >>>>> create a service account for a service running on a different machine. >>>>> >>>>> In this case it would be a service account for ovirt so that freeipa >>>>> users can authenticate in the ovirt portal using their freeipa >>>>> credentials. >>>> >>>> >>>> It sounds like that you do not want system user account, but you are OK >>>> with >>>> service account so that you can get a keytab for your oVirt instance. In >>>> that >>>> case, simple >>>> >>>> $ ipa service-add HTTP/frontend.ovirt.test >>>> and >>>> $ ipa-getkeytab ... >>>> should be enough, right? >>>> >>>> Maybe I just do not understand the use case. >>>> >>>>> I could ofcourse create an account and then apply a ldf to set its >>>>> password expiration to the next millennium to make sure the password >>>>> does not expire. >>>>> >>>>> Anybody who has a good suggestion on how to deal with this ? >>>>> >>>>> Cheers >>>>> Rob Verduijn >>>>> >>>> >>> >>> >>> >>> Hello, >>> >>> I think some more context should clear this up a bit. >>> >>> according to the rhev administrator guide: (ovirt referes to rhev manuals >>> a lot) >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html >>> >>> It talks about two options as a single sign on solution. >>> >>> On have the single sign on work for the portal, but then it won't work >>> for the vm's. >>> ( something about not being able to pass a password since the portal >>> won't have one to pass ) >>> >>> Or have the single sign on work for the vm's but than you have to sign >>> in to the portal so it can pass on your credentials to the vm's. >>> >>> I guess there is some interesting technical challenge to deal with to >>> merge those two cases. >>> >>> The first option requires privileges to browse the freeipa directory >>> to look for user accounts. >>> I do not know if that can be solved with something as simple as a >>> keytab and a pricipal. >>> >>> My current working solution is an account with a very long password >>> experation time in the freeipa directory >>> ( a random 32 character/number password is being used for this ) >>> >>> However something tells me that there is a more elegant solution. >>> And I was wondering if anyone knows one. >> >> >> Reading the HowTo, I think using normal FreeIPA POSIX user with password >> policy, uid, home and all the rings and bells may be an over kill. You could >> replica what is done with sudo system user for binding to LDAP for example: >> >> # ldapmodify -D "cn=Directory Manager" -x -W >> dn: uid=ovirt,cn=sysaccounts,cn=etc,$SUFFIX >> changetype: add >> objectclass: account >> objectclass: simplesecurityobject >> uid: sudo >> userPassword: $YOUR_PASSWORD >> passwordExpirationTime: 20380119031407Z >> nsIdleTimeout: 0 >> >> and use that as oVirt BIND user. As for keytab, you just would not use >> kadmin, but rather add the service object with "service-add" and get the >> keytab with "ipa-getkeytab". >> >> Other than that, the HowTo was mostly about oVirt side of configuration. >> >> If you succeed, it would nice to record your steps specific to FreeIPA in a >> HowTo article on FreeIPA :-) >> >> http://www.freeipa.org/page/HowTos >> http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki >> >> Martin From mbabinsk at redhat.com Mon Nov 23 08:34:12 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 23 Nov 2015 09:34:12 +0100 Subject: [Freeipa-users] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker) In-Reply-To: References: Message-ID: <5652CF84.1000907@redhat.com> On 11/20/2015 04:44 PM, Karl Forner wrote: > Hello, > > My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1. > The freeipa server runs inside a docker (an adelton/freeipa-server), and > the docker host pretends to be the freeIPA server by forwarding the > appropriate ports. > > This works very fine. > But when I reboot my server (which is in a locked server room. r), I > struggle to connect to it. > > I'm unable to connect using ssh onto it, using any kind of local or > freeIPA accounts onto it. > The DNS server (provided by freeIPA) works kine though (i.e. nslookup > server server works). > > Fortunately, I have the monit web app running on the server that allows > to restart the ssh service. > > After restarting ssh remotely. I am now able to connect to the server. > It seems that all works fine again once I restart sssd on the server. > > I know this is a pretty complex setup, but do you have hints that could > help me have a usable server after reboot ? > > Thanks, > Karl Forner > > > > > We will need some more information to help you out. Is the ssh daemon running right after the reboot? Is there anything in sshd logs? We may also need sssd logs, see https://fedorahosted.org/sssd/wiki/Troubleshooting. -- Martin^3 Babinsky From holosian at gmail.com Mon Nov 23 08:47:45 2015 From: holosian at gmail.com (holo) Date: Mon, 23 Nov 2015 09:47:45 +0100 Subject: [Freeipa-users] LDAP creditentials for Squid In-Reply-To: References: <1448056045.18336.12.camel@gmail.com> Message-ID: <1448268465.9788.7.camel@gmail.com> Hello, Thank you for reply. I used your links and i configured squid to use FreeIPA/LDAP to authenticate. IMy main problem was with connection to LDAP server cos i didnt have "Domain ?Manager" credentials for ldap and according to that doc:?http://www.freeipa.org/page/Howto/Change_Directo ry_Manager_Password?from that password depends other things in freeipa. I solve it such way: 1. Made backup of present configuration file -?dse.ldif 2. ?Changed password accroding to link: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpa ssword.html 3. Create LDAP user for squid like for ejabberd in this how to: http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDA P_Group_memberships 4. Restored backup of dse.ldif 5. Configured Squid to use ldap with new creditentials according to your link:?https://workaround.org/squid-ldap/ Everything is working like i was expected. Thank you for help //holo On Sat, 2015-11-21 at 06:53 +0100, Natxo Asenjo wrote: > hi, > > On Fri, Nov 20, 2015 at 10:47 PM, holo wrote: > > Hello > > > > How can i find FreeIPA ldap creditentials? I want to try to > > configure Squid in similar way like it is described here for > > ejabberd: > > > > http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using > > _LDAP_Group_memberships > > > > > I do not understand the question. Do you want to user ldap with > squid? > > Then you need to configure an authentication helper in squid. You > will find how to do that in the squid wiki: > > http://wiki.squid-cache.org/ConfigExamples/Authenticate/Ldap > > And for squid acls dependeing on ldap group membership take a look at > the examples here: > > https://workaround.org/squid-ldap/ > > If you have trouble configuring squid, then you should ask on the > squid mailing list (very active, very helpful). > -- > Groeten, > natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From holosian at gmail.com Mon Nov 23 08:51:53 2015 From: holosian at gmail.com (holo) Date: Mon, 23 Nov 2015 09:51:53 +0100 Subject: [Freeipa-users] Squid authentication in FreeIPA In-Reply-To: References: <1448054679.18336.8.camel@gmail.com> <1448055695.3784.34.camel@lgs.com.ve> <1448058064.18336.16.camel@gmail.com> Message-ID: <1448268713.9788.11.camel@gmail.com> Hello Yes that was my thread on severfault :) I solve my problem by using LDAP authentication instead of Kerberos and everything is working like i was expected right now. I needed login/password form in browser what is not supported by kerberos authentication in squid. //holo On Sat, 2015-11-21 at 06:57 +0100, Natxo Asenjo wrote: > hi holo, > > > On Fri, Nov 20, 2015 at 11:21 PM, holo wrote: > > Thank you for your reply.? > > > > I think i wasnt clear enough. Clients of proxy server are not > > kerberized. I want to just authenticate them for proxy use in > > kerberos DB when they are trying to use it (just by popup like in > > NTLM). Is such thing possible with kerberos? I saw on yt such thing > > wasa posible with AD. > > > > //holo > > > did you ask this question in serverfault as well :-) ? > > http://serverfault.com/questions/737902/squid-kerberos-authentication > -no-popup/737909#737909 > > If you require ntlm, then you should joing the squid host to an AD > realm, I do not think this will work with freeipa because it does not > do ntlm as far as I know. > ? > -- > Groeten, > natxo > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdh at dds.nl Mon Nov 23 09:50:07 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 23 Nov 2015 10:50:07 +0100 Subject: [Freeipa-users] FreeIPA en Domain Trust Message-ID: <5652E14F.8050708@dds.nl> An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Nov 23 09:54:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Nov 2015 10:54:03 +0100 Subject: [Freeipa-users] FreeIPA en Domain Trust In-Reply-To: <5652E14F.8050708@dds.nl> References: <5652E14F.8050708@dds.nl> Message-ID: <5652E23B.50308@redhat.com> On 11/23/2015 10:50 AM, Winfried de Heiden wrote: > Hi all, > > For some reason, we only want to use the Active Directory user from an Active > Directory using a Trust. (groups like "Domain Users" are of no use...) > > Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/ > > Kinds Regards, > > Winny This looks as a question for the client part (SSSD). I do not fully understand the use case, you want to allow AD user to authenticate to Linux box, but you do not want the Linux box to see any of the AD groups? What is the motivation, if I may ask? From jpazdziora at redhat.com Mon Nov 23 09:58:22 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 23 Nov 2015 10:58:22 +0100 Subject: [Freeipa-users] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker) In-Reply-To: References: Message-ID: <20151123095822.GB9346@redhat.com> On Fri, Nov 20, 2015 at 04:44:38PM +0100, Karl Forner wrote: > > My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1. > The freeipa server runs inside a docker (an adelton/freeipa-server), and > the docker host pretends to be the freeIPA server by forwarding the > appropriate ports. Is the Docker host the same machine that runs that sssd 1.12.5-1~trusty1 and that you try to ssh to? Assuming it's the same machine, when you IPA-enrolled the host machine, was Docker container's internal (172.*) IP address used or the public interface of the host? > I'm unable to connect using ssh onto it, using any kind of local or freeIPA > accounts onto it. What does ssh -v root at the-host say? Do you fail to connect or do you fail to authenticate? How do you try to authenticate -- Kerberos ticket (kinit on client) or using password on sshd prompt? > The DNS server (provided by freeIPA) works kine though (i.e. nslookup > server server works). And does it return the correct IP address, the public address of the host? > Fortunately, I have the monit web app running on the server that allows to > restart the ssh service. > > After restarting ssh remotely. I am now able to connect to the server. > It seems that all works fine again once I restart sssd on the server. Do you restart the sshd service, sssd service, or both? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jhrozek at redhat.com Mon Nov 23 10:18:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Nov 2015 11:18:28 +0100 Subject: [Freeipa-users] FreeIPA en Domain Trust In-Reply-To: <5652E23B.50308@redhat.com> References: <5652E14F.8050708@dds.nl> <5652E23B.50308@redhat.com> Message-ID: <20151123101828.GH12432@hendrix> On Mon, Nov 23, 2015 at 10:54:03AM +0100, Martin Kosek wrote: > On 11/23/2015 10:50 AM, Winfried de Heiden wrote: > > Hi all, > > > > For some reason, we only want to use the Active Directory user from an Active > > Directory using a Trust. (groups like "Domain Users" are of no use...) > > > > Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/ > > > > Kinds Regards, > > > > Winny > > This looks as a question for the client part (SSSD). I do not fully understand > the use case, you want to allow AD user to authenticate to Linux box, but you > do not want the Linux box to see any of the AD groups? What is the motivation, > if I may ask? > I don't think this is possible, at least not until there would be a separate subdomain configuration. At the moment, most of the subdomain configuration is just the defaults. But I don't see the reason either, at most the groups would be able to own resources on IPA-managed boxes.. From roberto.cornacchia at gmail.com Mon Nov 23 10:33:34 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Nov 2015 11:33:34 +0100 Subject: [Freeipa-users] Unspecified GSS failure. No credentials cache found Message-ID: Hi there, Although I can't see anything failing, the logs of all clients in my IPA domain (FC22, freeipa 4.1.4) contain lots of these failures every day: nov 23 10:43:34 hadron.hq.example.com gssproxy[742]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Do you have suggestions on how to find out what the problem might be? Or is this something I should not worry about? Thanks, Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Nov 23 11:50:47 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Nov 2015 12:50:47 +0100 Subject: [Freeipa-users] web ui runtime error In-Reply-To: <56528BBA.9050808@cora.nwra.com> References: <56528BBA.9050808@cora.nwra.com> Message-ID: <5652FD97.8070103@redhat.com> On 11/23/2015 04:44 AM, Orion Poplawski wrote: > Trying to install freeipa-server on Fedora 23. When I try to connect to > the web UI from a non-domain EL7 client with firefox I get: > > > Runtime error > > Web UI got in unrecoverable state during "init" phase > Technical details: > The operation is insecure. Does the browser trust IPA CA? If you open Firefox developer tools (usually F12 key). In "network monitor" after page refresh which(if any) network requests have status other than "200 success" - first column? > .cache["freeipa/app_container"]/ > .cache["dojo/_base/lang"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["dojo/_base/array"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["dojo/_base/lang"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["dojo/_base/lang"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["dojo/_base/lang"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/_base/Phase_controller"]/ > .cache["freeipa/app_container"]/ > .cache["dojo/_base/lang"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["freeipa/plugin_loader"]/ > .cache["dojo/Deferred"]/ > .cache["dojo/Deferred"]/ > .cache["freeipa/plugin_loader"]/ > .cache["dojo/_base/lang"]/ > Vt at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726 > Zt at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899 > nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085 > tn at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961 > nn at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025 > ln/i at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123 > p.injectUrl/i at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:12306 > > > > Do I have to do something to enable username/password auth for this > version of IPA? > -- Petr Vobornik From simo at redhat.com Mon Nov 23 15:36:39 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 10:36:39 -0500 Subject: [Freeipa-users] Active Directory Integration and limitations In-Reply-To: References: Message-ID: <1448292999.7892.22.camel@redhat.com> On Wed, 2015-11-18 at 11:46 +0100, Domineaux Philippe wrote: > Here is my environment : > > 1 Windows Domain > Windows workstations > Windows servers > Multiple linux domains > Linux workstations > Linux servers > > Here is my goal : > > All users are centralized in the Active Directory. > Users will authenticate on linux workstations with their AD accounts ( > using POSIX attributes). > Linux workstations must have access to NFS shares on Linux servers. Hi Domineaux, you should look into setting up FreeIPA with a trust relationship to the Windows Domain. > What are the limitations ? It is hard to say what kind of limitations you are interested into, when we trust AD, then AD users can access Linux machines, one limitation (if you think it is a limitation) is that AD users will have fully qualified names on the host (example: user at ad.example.com) and not just flat names to avoid name clashes between ipa users, local users and AD users. > Windows users equals ipa users in term of services ? Yes. > Do I have to configure kerberos to also join directly the Windows Kerberos > Realm, > or will IPA do the job to ask Windows server ? If you set up a trust between servers all is taken care of for you wrt clients. > in etc/krb5.conf : > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = IPA.ORG > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > canonicalize = yes > allow_weak_crypto = true > > [realms] > IPA.ORG = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = RULE:[1:$1@ > $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ > auth_to_local = DEFAULT > > } > > ### IS THIS NECESSARY > WINDOMAIN.LOCAL = { > kdc = srvadipa.windomain.local > admin_server = srvadipa.windomain.local > } > > > [domain_realm] > .cosmo.org = COSMO.ORG > cosmo.org = COSMO.ORG > > ### IS THIS NECESSARY > > .windomain.local = WINDOMAIN.LOCAL > windomain.local = WINDOMAIN.LOCAL It depends on what client you are using, older RHEL may need this, newer ones have an include directory in krb5.conf and sssd generates appropriate configuration automatically based on server configuration. > Is the bug in libnfsidmap still active and prevents Windows users to access > to NFS4 krb5 secured shared folder ? I am not sure what bug you refer to. You may need to configure nfs client nfs idmap, but I am not aware of bugs that will prevent it from working right if properly configured. Specifically you may want to *not* try to consult LDAP from idmap, but use a regex to transform the windows realm from upper case to lowercase and then just use the getpwnam interface. Simo. > I currently have > > bug here: > https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html > -- > 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 -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Nov 23 15:38:36 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 10:38:36 -0500 Subject: [Freeipa-users] "ASN.1 structure is missing a required field" - what is missing? In-Reply-To: References: Message-ID: <1448293116.7892.24.camel@redhat.com> On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote: > I'm putting together a java kerberos client and am having an issue > getting a SGT form IPA. I get a TGT without issue, but when I submit > the TGS-REQ I get the following errors in the ipa log: > > Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 > etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17 > tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > krbtgt/RHELENT.LAN at RHELENT.LAN > > Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 > etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0, > for HTTP/ipa.rhelent.lan at RHELENT.LAN, ASN.1 structure is missing a > required field > > Here's the TGS request: > > Kerberos > tgs-req > pvno: 5 > msg-type: krb-tgs-req (12) > padata: 1 item > PA-DATA PA-TGS-REQ > padata-type: kRB5-PADATA-TGS-REQ (1) > padata-value: > 6e8201f8308201f4a003020105a10302010ea20703050000... > ap-req > pvno: 5 > msg-type: krb-ap-req (14) > Padding: 0 > ap-options: 00000000 > 0... .... = reserved: False > .0.. .... = use-session-key: False > ..0. .... = mutual-required: False > ticket > tkt-vno: 5 > realm: RHELENT.LAN > sname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 2 items > KerberosString: krbtgt > KerberosString: RHELENT.LAN > enc-part > etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > kvno: 1 > cipher: > 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11... > authenticator > etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) > kvno: 255 > cipher: > f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74... > req-body > Padding: 0 > kdc-options: 00000000 > 0... .... = reserved: False > .0.. .... = forwardable: False > ..0. .... = forwarded: False > ...0 .... = proxiable: False > .... 0... = proxy: False > .... .0.. = allow-postdate: False > .... ..0. = postdated: False > .... ...0 = unused7: False > 0... .... = renewable: False > .0.. .... = unused9: False > ..0. .... = unused10: False > ...0 .... = opt-hardware-auth: False > .... ..0. = request-anonymous: False > .... ...0 = canonicalize: False > 0... .... = constrained-delegation: False > ..0. .... = disable-transited-check: False > ...0 .... = renewable-ok: False > .... 0... = enc-tkt-in-skey: False > .... ..0. = renew: False > .... ...0 = validate: False > cname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 2 items > KerberosString: HTTP > KerberosString: s4u.rhelent.lan > realm: RHELENT.LAN > sname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 2 items > KerberosString: HTTP > KerberosString: ipa.rhelent.lan > from: 2015-11-18 02:17:44 (UTC) > till: 2015-11-18 10:17:44 (UTC) > nonce: 604310537 > etype: 1 item > ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) > > > Is there a field missing? CCing Andreas as this one sounds like a bug we recently discovered in the ASN.1 parser in samba. Andreas, does this ring a bell ? Marc, what version of IPA/OS are you seeing this on ? Simo. -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Mon Nov 23 15:41:11 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 23 Nov 2015 10:41:11 -0500 Subject: [Freeipa-users] "ASN.1 structure is missing a required field" - what is missing? In-Reply-To: <1448293116.7892.24.camel@redhat.com> References: <1448293116.7892.24.camel@redhat.com> Message-ID: We actually tracked it down. The problem was the Authenticator was missing the authenticatorkvno field per the RFC. Once we set that to 5 we got past this issue. IPA 4.1 on CentOS7 Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com On Mon, Nov 23, 2015 at 10:38 AM, Simo Sorce wrote: > On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote: >> I'm putting together a java kerberos client and am having an issue >> getting a SGT form IPA. I get a TGT without issue, but when I submit >> the TGS-REQ I get the following errors in the ipa log: >> >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 >> etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17 >> tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for >> krbtgt/RHELENT.LAN at RHELENT.LAN >> >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 >> etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0, >> for HTTP/ipa.rhelent.lan at RHELENT.LAN, ASN.1 structure is missing a >> required field >> >> Here's the TGS request: >> >> Kerberos >> tgs-req >> pvno: 5 >> msg-type: krb-tgs-req (12) >> padata: 1 item >> PA-DATA PA-TGS-REQ >> padata-type: kRB5-PADATA-TGS-REQ (1) >> padata-value: >> 6e8201f8308201f4a003020105a10302010ea20703050000... >> ap-req >> pvno: 5 >> msg-type: krb-ap-req (14) >> Padding: 0 >> ap-options: 00000000 >> 0... .... = reserved: False >> .0.. .... = use-session-key: False >> ..0. .... = mutual-required: False >> ticket >> tkt-vno: 5 >> realm: RHELENT.LAN >> sname >> name-type: kRB5-NT-PRINCIPAL (1) >> name-string: 2 items >> KerberosString: krbtgt >> KerberosString: RHELENT.LAN >> enc-part >> etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) >> kvno: 1 >> cipher: >> 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11... >> authenticator >> etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) >> kvno: 255 >> cipher: >> f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74... >> req-body >> Padding: 0 >> kdc-options: 00000000 >> 0... .... = reserved: False >> .0.. .... = forwardable: False >> ..0. .... = forwarded: False >> ...0 .... = proxiable: False >> .... 0... = proxy: False >> .... .0.. = allow-postdate: False >> .... ..0. = postdated: False >> .... ...0 = unused7: False >> 0... .... = renewable: False >> .0.. .... = unused9: False >> ..0. .... = unused10: False >> ...0 .... = opt-hardware-auth: False >> .... ..0. = request-anonymous: False >> .... ...0 = canonicalize: False >> 0... .... = constrained-delegation: False >> ..0. .... = disable-transited-check: False >> ...0 .... = renewable-ok: False >> .... 0... = enc-tkt-in-skey: False >> .... ..0. = renew: False >> .... ...0 = validate: False >> cname >> name-type: kRB5-NT-PRINCIPAL (1) >> name-string: 2 items >> KerberosString: HTTP >> KerberosString: s4u.rhelent.lan >> realm: RHELENT.LAN >> sname >> name-type: kRB5-NT-PRINCIPAL (1) >> name-string: 2 items >> KerberosString: HTTP >> KerberosString: ipa.rhelent.lan >> from: 2015-11-18 02:17:44 (UTC) >> till: 2015-11-18 10:17:44 (UTC) >> nonce: 604310537 >> etype: 1 item >> ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) >> >> >> Is there a field missing? > > CCing Andreas as this one sounds like a bug we recently discovered in > the ASN.1 parser in samba. > > Andreas, > does this ring a bell ? > > Marc, > what version of IPA/OS are you seeing this on ? > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > From wdh at dds.nl Mon Nov 23 15:43:11 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 23 Nov 2015 16:43:11 +0100 Subject: [Freeipa-users] Fwd: Re: FreeIPA en Domain Trust In-Reply-To: <5652E351.7060904@dds.nl> References: <5652E351.7060904@dds.nl> Message-ID: <5653340F.8090707@dds.nl> An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 23 15:43:48 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 10:43:48 -0500 Subject: [Freeipa-users] [Solved] Re: "ASN.1 structure is missing a required field" - what is missing? In-Reply-To: References: <1448293116.7892.24.camel@redhat.com> Message-ID: <1448293428.7892.25.camel@redhat.com> On Mon, 2015-11-23 at 10:41 -0500, Marc Boorshtein wrote: > We actually tracked it down. The problem was the Authenticator was > missing the authenticatorkvno field per the RFC. Once we set that to > 5 we got past this issue. Ok, then we'll considered this solved, thanks for following up. Simo. > IPA 4.1 on CentOS7 > > Thanks > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > > > > On Mon, Nov 23, 2015 at 10:38 AM, Simo Sorce wrote: > > On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote: > >> I'm putting together a java kerberos client and am having an issue > >> getting a SGT form IPA. I get a TGT without issue, but when I submit > >> the TGS-REQ I get the following errors in the ipa log: > >> > >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 > >> etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17 > >> tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > >> krbtgt/RHELENT.LAN at RHELENT.LAN > >> > >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 > >> etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0, > >> for HTTP/ipa.rhelent.lan at RHELENT.LAN, ASN.1 structure is missing a > >> required field > >> > >> Here's the TGS request: > >> > >> Kerberos > >> tgs-req > >> pvno: 5 > >> msg-type: krb-tgs-req (12) > >> padata: 1 item > >> PA-DATA PA-TGS-REQ > >> padata-type: kRB5-PADATA-TGS-REQ (1) > >> padata-value: > >> 6e8201f8308201f4a003020105a10302010ea20703050000... > >> ap-req > >> pvno: 5 > >> msg-type: krb-ap-req (14) > >> Padding: 0 > >> ap-options: 00000000 > >> 0... .... = reserved: False > >> .0.. .... = use-session-key: False > >> ..0. .... = mutual-required: False > >> ticket > >> tkt-vno: 5 > >> realm: RHELENT.LAN > >> sname > >> name-type: kRB5-NT-PRINCIPAL (1) > >> name-string: 2 items > >> KerberosString: krbtgt > >> KerberosString: RHELENT.LAN > >> enc-part > >> etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > >> kvno: 1 > >> cipher: > >> 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11... > >> authenticator > >> etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) > >> kvno: 255 > >> cipher: > >> f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74... > >> req-body > >> Padding: 0 > >> kdc-options: 00000000 > >> 0... .... = reserved: False > >> .0.. .... = forwardable: False > >> ..0. .... = forwarded: False > >> ...0 .... = proxiable: False > >> .... 0... = proxy: False > >> .... .0.. = allow-postdate: False > >> .... ..0. = postdated: False > >> .... ...0 = unused7: False > >> 0... .... = renewable: False > >> .0.. .... = unused9: False > >> ..0. .... = unused10: False > >> ...0 .... = opt-hardware-auth: False > >> .... ..0. = request-anonymous: False > >> .... ...0 = canonicalize: False > >> 0... .... = constrained-delegation: False > >> ..0. .... = disable-transited-check: False > >> ...0 .... = renewable-ok: False > >> .... 0... = enc-tkt-in-skey: False > >> .... ..0. = renew: False > >> .... ...0 = validate: False > >> cname > >> name-type: kRB5-NT-PRINCIPAL (1) > >> name-string: 2 items > >> KerberosString: HTTP > >> KerberosString: s4u.rhelent.lan > >> realm: RHELENT.LAN > >> sname > >> name-type: kRB5-NT-PRINCIPAL (1) > >> name-string: 2 items > >> KerberosString: HTTP > >> KerberosString: ipa.rhelent.lan > >> from: 2015-11-18 02:17:44 (UTC) > >> till: 2015-11-18 10:17:44 (UTC) > >> nonce: 604310537 > >> etype: 1 item > >> ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) > >> > >> > >> Is there a field missing? > > > > CCing Andreas as this one sounds like a bug we recently discovered in > > the ASN.1 parser in samba. > > > > Andreas, > > does this ring a bell ? > > > > Marc, > > what version of IPA/OS are you seeing this on ? > > > > Simo. > > > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Mon Nov 23 15:50:22 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Nov 2015 16:50:22 +0100 Subject: [Freeipa-users] Fwd: Re: FreeIPA en Domain Trust In-Reply-To: <5653340F.8090707@dds.nl> References: <5652E351.7060904@dds.nl> <5653340F.8090707@dds.nl> Message-ID: <20151123155022.GQ12432@hendrix> On Mon, Nov 23, 2015 at 04:43:11PM +0100, Winfried de Heiden wrote: > Hi all, > > One motivation: the customer demands like this... Yes, but why? It doesn't make sense to me.. > Also: ignore Windows specific group info which is not important for the > Linux domain > Also: too much groups! > > If it's a sssd thing, this might be solved on the IPA-server as well since > getting the AD group info is handles by sssd on the IPA-server, right? > Anyway: how to handle this issue? Can't be done at the moment short of blacklisting each and every group using filter_groups or min_id/max_id ranges. Both are hacks that should be avoided, though.. The reason is that the trusted domain configuration on the SSSD side is more or less always using defaults and things like search bases can't be set for the subdomain at the moment. > > Kind regards, > > Winny > Op 23-11-15 om 10:54 schreef Martin Kosek: > > On 11/23/2015 10:50 AM, Winfried de Heiden wrote: > > Hi all, > > For some reason, we only want to use the Active Directory user from an Active > Directory using a Trust. (groups like "Domain Users" are of no use...) > > Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/ > > Kinds Regards, > > Winny > > This looks as a question for the client part (SSSD). I do not fully understand > the use case, you want to allow AD user to authenticate to Linux box, but you > do not want the Linux box to see any of the AD groups? What is the motivation, > if I may ask? > -- > 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 From wdh at dds.nl Mon Nov 23 15:55:31 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 23 Nov 2015 16:55:31 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed Message-ID: <565336F3.1070402@dds.nl> An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Nov 23 16:16:26 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Nov 2015 17:16:26 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <565336F3.1070402@dds.nl> References: <565336F3.1070402@dds.nl> Message-ID: <20151123161626.GR12432@hendrix> On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote: > Hi all, > > I created some hbac rule on freeipa-server 4.1.4 on Fedora 22 > > # ipa hbacrule-show testuser > ? Rule name: testuser > ? Enabled: TRUE > ? Users: testuser > ? Hosts: fedora23-server.blabla.bla > ? Services: sshd > > Hence, " testuser"? is only allowed using sshd on "fedora23-server". No > surprise, this user is not allowed to use "su": > > # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service > su > --------------------- > Access granted: False > > (and yeah sshd is allowed) > > However, doing a "su"? on the fedora23-server.blabla.bla, and giving the > correct password, access is granted. This user is not a member of any > other groups. > HBAC Services like cron or console access are denied correctly since they > are not in the HBAC service list. > > I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several > other ipa-clients (RHEL/CentoOS 6.x, 7.x) > > Shouldn't su or su -l be denied when not listed? Yes, and in my testing with a similar rule: $ ipa hbacrule-show allow_sshd Rule name: allow_sshd Enabled: TRUE Users: admin Hosts: client.ipa.test Services: sshd admin can ssh to client.ipa.test but it's not possible to su to admin. Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check /var/log/secure and the sssd logs. Also, you're not calling su as root, are you? From sbose at redhat.com Mon Nov 23 16:47:34 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 23 Nov 2015 17:47:34 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <20151123161626.GR12432@hendrix> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> Message-ID: <20151123164734.GE26935@p.redhat.com> On Mon, Nov 23, 2015 at 05:16:26PM +0100, Jakub Hrozek wrote: > On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote: > > Hi all, > > > > I created some hbac rule on freeipa-server 4.1.4 on Fedora 22 > > > > # ipa hbacrule-show testuser > > ? Rule name: testuser > > ? Enabled: TRUE > > ? Users: testuser > > ? Hosts: fedora23-server.blabla.bla > > ? Services: sshd > > > > Hence, " testuser"? is only allowed using sshd on "fedora23-server". No > > surprise, this user is not allowed to use "su": > > > > # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service > > su > > --------------------- > > Access granted: False > > > > (and yeah sshd is allowed) > > > > However, doing a "su"? on the fedora23-server.blabla.bla, and giving the > > correct password, access is granted. This user is not a member of any > > other groups. > > HBAC Services like cron or console access are denied correctly since they > > are not in the HBAC service list. > > > > I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several > > other ipa-clients (RHEL/CentoOS 6.x, 7.x) > > > > Shouldn't su or su -l be denied when not listed? > > Yes, and in my testing with a similar rule: > > $ ipa hbacrule-show allow_sshd > Rule name: allow_sshd > Enabled: TRUE > Users: admin > Hosts: client.ipa.test > Services: sshd > > admin can ssh to client.ipa.test but it's not possible to su to admin. > > Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check > /var/log/secure and the sssd logs. > > Also, you're not calling su as root, are you? Have you disabled the allow_all rule? bye, Sumit > > -- > 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 From mbasti at redhat.com Mon Nov 23 16:55:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Nov 2015 17:55:43 +0100 Subject: [Freeipa-users] freeipa harware appliance In-Reply-To: References: <564F586E.3030505@redhat.com> Message-ID: <5653450F.9040403@redhat.com> On 20.11.2015 18:37, Karl Forner wrote: > Thanks Martin. > My expected numbers: users ~ 50 max, concurrent clients/sessions < 20, > hosts < 20. > I was thinking about a server with an old intel cpu, 4Gb RAM and smal > HDD or USB key-based storage + an ethernet port. > I have no idea if it is a common use in IT to run such (critical) > application on its own dedicated appliance. This configuration should be enough. Virtualization is everywhere, many users use IPA in virtualized environment :-) > > > > On Fri, Nov 20, 2015 at 6:29 PM, Martin Basti > wrote: > > > > On 20.11.2015 16:47, Karl Forner wrote: >> Hello, >> >> Could you recommend me a mini appliance/server to use as a >> freeIPA server ? >> I guess the main points are an ethernet port, minimal >> consumption, robustness. >> >> Thanks, >> Karl Forner >> >> > Hello, > > I would say that minimal amount of RAM is 2GB with IPA 4.2, of > course amount of resources depends on many things. > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Preparing_for_an_IPA_Installation-Hardware_Requirements.html > > Disk space at least 500MB for basic installation + baseOS + stored > data > > I do not know if IPA is limited by a CPU in somehow, but with very > slow CPU you may need to increase timeouts (I saw the posts on > this lists that it is possible to run IPA on raspberry pi with > increased timeouts) > > Maybe would be better if you write what do you need this minimal > configuration for and how many clients, users and connections > should IPA handle. > > Martin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstormshak at cccis.com Tue Nov 24 02:05:15 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 24 Nov 2015 02:05:15 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <20151123075846.GA12432@hendrix> References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> Message-ID: Jakub/Rob - Thanks for the feedback. I was finally able to ditch the ?binddn? and was able to get SSL working upon upgrading the OpenSSL from the 5.5 base to the one supplied in 5.7 base. The SSL is fully authenticating and with sudo access. However, I?m riddled by the following item below. I?m hoping that someone/somewhere encountered this issue and was able to resolve it using this legacy 5.5. See details provided below. All thoughts/suggestions are truly appreciated !! $ id -a uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) $ passwd Changing password for user pmoss. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Insufficient access Insufficient 'write' privilege to the 'userPassword' attribute of entry 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. passwd: Permission denied # ipa user-show pmoss --all --rights | grep -i userpass -> attributelevelrights: {u'userpassword': u'swo?, ? pmoss shows u'userpassword': u'swo' ?swo? translates to ?search,write,delete? Why wouldn?t the above be enough rights to be able to change ?pmoss? personal password? Thoughts ? Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Jakub Hrozek > Date: Monday, November 23, 2015 at 1:58 AM To: Jeffrey Stormshak > Cc: Rob Crittenden >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: Rob - Here?s the test configurations/data when I manipulate the BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux 5.5. I have three questions below that I would like to get your comments on or see what you may recommend on this. I?m seriously perplexed on this as to why its working this way ? Please advise. Thanks! ************************************************************** AUTH successful on login; SUDO fails with the message listed below !! ************************************************************** [mjsmith at chi-infra-idm-client2 ~]$ sudo -l sudo: ldap_sasl_bind_s(): Server is unwilling to perform Looks like the bind didn't finish successfully, can you look into debugging sudo itself? The debugging changed a bit between releases, but The sudo documentation would tell you.. [sudo] password for mjsmith: Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. ***************************************************** ***************************************************** # grep -iv ?#? /etc/ldap.conf ***************************************************** base dc=linuxcccis,dc=com uri ldap://chi-infra-idm-p1.linuxcccis.com/ binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com bindpw secret_pass timelimit 15 bind_timelimit 5 idle_timelimit 3600 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm pam_password md5 sudoers_base ou=SUDOers,dc=linuxcccis,dc=com ************************************************* User Account AUTH and SUDO works when commenting both the binddn and bindpw fields !! ************************************************* vi /etc/ldap.conf ? Comment these two fields ? #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com #bindpw secret_pass ************************************************ This file unchanged during the above testing !! ************************************************ /etc/sudo-ldap.conf: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com bindpw secret_pass ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://chi-infra-idm-p1.linuxcccis.com sudoers_base ou=SUDOers,dc=linuxcccis,dc=com QUESTIONS: 1) What BINDN account needs to be specified to allow the BINDDN/BINDPW to work for SUDO? 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, but SUDO then fails? 3) If I leave BINDDN/BINDPW blank, what security risks are being introduced by leaving it that way? Anyone on the network can read sudo rules. I guess in theory, the attacker might target accounts who are allowed to run sudo rules as a gateway for getting elevated privileges on the machine.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 24 02:32:52 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Nov 2015 21:32:52 -0500 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <20151117085555.GD3768@hendrix.arn.redhat.com> <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> Message-ID: <5653CC54.5070609@redhat.com> Jeffrey Stormshak wrote: > Jakub/Rob - > Thanks for the feedback. I was finally able to ditch the ?binddn? and > was able to get SSL working upon upgrading the OpenSSL from the 5.5 base > to the one supplied in 5.7 base. The SSL is fully authenticating and > with sudo access. However, I?m riddled by the following item below. > I?m hoping that someone/somewhere encountered this issue and was able > to resolve it using this legacy 5.5. See details provided below. All > thoughts/suggestions are truly appreciated !! > > * > * > > $ id -a > > uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) > > > > $ passwd > > Changing password for user pmoss. > > Enter login(LDAP) password: > > New UNIX password: > > Retype new UNIX password: > > > > LDAP password information update failed: Insufficient access > > Insufficient 'write' privilege to the 'userPassword' attribute of entry > 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. > > > > passwd: Permission denied > > * > * > > # ipa user-show pmoss --all --rights | grep -i userpass -> > attributelevelrights: {u'userpassword': u'swo?, ? > > > pmoss shows *u'userpassword': u'swo'* > > ?swo? translates to ?search,write,delete? > > > Why wouldn?t the above be enough rights to be able to change ?pmoss? > personal password? Thoughts ? Because it is a different part of the tree. Did you use ipa-advise to get the configuration? If so which profile? It looks like that recommends using the compat tree. It's been forever since I've manually configured a RHEL 5 system so I don't know if that is correct or not. I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a distant memory. rob > *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer* > > Platform Systems | IT Operations Infrastructure > > CCC Information Services, Inc. > > Phone: (312) 229-2552 > > > From: Jakub Hrozek > > Date: Monday, November 23, 2015 at 1:58 AM > To: Jeffrey Stormshak > > Cc: Rob Crittenden >, > "freeipa-users at redhat.com " > > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > > Rob - > Here?s the test configurations/data when I manipulate the > BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux > 5.5. I have three questions below that I would like to get your > comments on or see what you may recommend on this. I?m seriously > perplexed on this as to why its working this way ? Please > advise. Thanks! > ************************************************************** > AUTH successful on login; SUDO fails with the message listed > below !! > ************************************************************** > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > sudo: ldap_sasl_bind_s(): Server is unwilling to perform > > > Looks like the bind didn't finish successfully, can you look into > debugging sudo itself? The debugging changed a bit between releases, but > The sudo documentation would tell you.. > > [sudo] password for mjsmith: > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > ***************************************************** > ***************************************************** > # grep -iv ?#? /etc/ldap.conf > ***************************************************** > base dc=linuxcccis,dc=com > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > bindpw secret_pass > timelimit 15 > bind_timelimit 5 > idle_timelimit 3600 > nss_initgroups_ignoreusers > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > pam_password md5 > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > ************************************************* > User Account AUTH and SUDO works when > commenting both the binddn and bindpw fields !! > ************************************************* > vi /etc/ldap.conf ? Comment these two fields ? > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > #bindpw secret_pass > ************************************************ > This file unchanged during the above testing !! > ************************************************ > /etc/sudo-ldap.conf: > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > bindpw secret_pass > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > bind_timelimit 5 > timelimit 15 > uri ldap://chi-infra-idm-p1.linuxcccis.com > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > QUESTIONS: > 1) What BINDN account needs to be specified to allow the > BINDDN/BINDPW to work for SUDO? > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, > but SUDO then fails? > 3) If I leave BINDDN/BINDPW blank, what security risks are being > introduced by leaving it that way? > > > Anyone on the network can read sudo rules. I guess in theory, the > attacker might target accounts who are allowed to run sudo rules as a > gateway for getting elevated privileges on the machine.. > From orion at cora.nwra.com Tue Nov 24 04:24:59 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 23 Nov 2015 21:24:59 -0700 Subject: [Freeipa-users] web ui runtime error In-Reply-To: <5652FD97.8070103@redhat.com> References: <56528BBA.9050808@cora.nwra.com> <5652FD97.8070103@redhat.com> Message-ID: <5653E69B.2030001@cora.nwra.com> On 11/23/2015 04:50 AM, Petr Vobornik wrote: > On 11/23/2015 04:44 AM, Orion Poplawski wrote: >> Trying to install freeipa-server on Fedora 23. When I try to connect to >> the web UI from a non-domain EL7 client with firefox I get: >> >> >> Runtime error >> >> Web UI got in unrecoverable state during "init" phase >> Technical details: >> The operation is insecure. > > Does the browser trust IPA CA? I believe I've now imported the CA, but no difference. > > If you open Firefox developer tools (usually F12 key). In "network > monitor" after page refresh which(if any) network requests have status > other than "200 success" - first column? Everything is 200 or 304 (not modified) > > >> .cache["freeipa/app_container"]/> >> >> .cache["dojo/_base/lang"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["dojo/_base/array"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["dojo/_base/lang"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["dojo/_base/lang"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["dojo/_base/lang"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/_base/Phase_controller"]/> >> >> .cache["freeipa/app_container"]/> >> >> .cache["dojo/_base/lang"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["freeipa/plugin_loader"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["dojo/Deferred"]/> >> >> .cache["freeipa/plugin_loader"]/> >> >> .cache["dojo/_base/lang"]/> >> >> Vt at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726 >> Zt at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899 >> nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085 >> tn at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961 >> nn at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025 >> ln/i at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123 >> p.injectUrl/i at https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:12306 >> >> >> >> >> Do I have to do something to enable username/password auth for this >> version of IPA? >> > > -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jhrozek at redhat.com Tue Nov 24 08:25:07 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 09:25:07 +0100 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <5653CC54.5070609@redhat.com> References: <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> Message-ID: <20151124082507.GU12432@hendrix> On Mon, Nov 23, 2015 at 09:32:52PM -0500, Rob Crittenden wrote: > Jeffrey Stormshak wrote: > > Jakub/Rob - > > Thanks for the feedback. I was finally able to ditch the ?binddn? and > > was able to get SSL working upon upgrading the OpenSSL from the 5.5 base > > to the one supplied in 5.7 base. The SSL is fully authenticating and > > with sudo access. However, I?m riddled by the following item below. > > I?m hoping that someone/somewhere encountered this issue and was able > > to resolve it using this legacy 5.5. See details provided below. All > > thoughts/suggestions are truly appreciated !! > > > > * > > * > > > > $ id -a > > > > uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) > > > > > > > > $ passwd > > > > Changing password for user pmoss. > > > > Enter login(LDAP) password: > > > > New UNIX password: > > > > Retype new UNIX password: > > > > > > > > LDAP password information update failed: Insufficient access > > > > Insufficient 'write' privilege to the 'userPassword' attribute of entry > > 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. > > > > > > > > passwd: Permission denied > > > > * > > * > > > > # ipa user-show pmoss --all --rights | grep -i userpass -> > > attributelevelrights: {u'userpassword': u'swo?, ? > > > > > > pmoss shows *u'userpassword': u'swo'* > > > > ?swo? translates to ?search,write,delete? > > > > > > Why wouldn?t the above be enough rights to be able to change ?pmoss? > > personal password? Thoughts ? > > Because it is a different part of the tree. > > Did you use ipa-advise to get the configuration? If so which profile? > > It looks like that recommends using the compat tree. It's been forever > since I've manually configured a RHEL 5 system so I don't know if that > is correct or not. Using the compat tree for users and groups (which implies id_provider=ldap, not ipa) is the right thing to do if you also want to use AD trust users on an RHEL-5 client. Otherwise, just use id_provider=ipa (but still point sudo to ou=sudoers) > > I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a > distant memory. > > rob > > > *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer* > > > > Platform Systems | IT Operations Infrastructure > > > > CCC Information Services, Inc. > > > > Phone: (312) 229-2552 > > > > > > From: Jakub Hrozek > > > Date: Monday, November 23, 2015 at 1:58 AM > > To: Jeffrey Stormshak > > > Cc: Rob Crittenden >, > > "freeipa-users at redhat.com " > > > > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > > > On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > > > > Rob - > > Here?s the test configurations/data when I manipulate the > > BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux > > 5.5. I have three questions below that I would like to get your > > comments on or see what you may recommend on this. I?m seriously > > perplexed on this as to why its working this way ? Please > > advise. Thanks! > > ************************************************************** > > AUTH successful on login; SUDO fails with the message listed > > below !! > > ************************************************************** > > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > > sudo: ldap_sasl_bind_s(): Server is unwilling to perform > > > > > > Looks like the bind didn't finish successfully, can you look into > > debugging sudo itself? The debugging changed a bit between releases, but > > The sudo documentation would tell you.. > > > > [sudo] password for mjsmith: > > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > > ***************************************************** > > ***************************************************** > > # grep -iv ?#? /etc/ldap.conf > > ***************************************************** > > base dc=linuxcccis,dc=com > > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > > bindpw secret_pass > > timelimit 15 > > bind_timelimit 5 > > idle_timelimit 3600 > > nss_initgroups_ignoreusers > > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > > pam_password md5 > > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > ************************************************* > > User Account AUTH and SUDO works when > > commenting both the binddn and bindpw fields !! > > ************************************************* > > vi /etc/ldap.conf ? Comment these two fields ? > > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > > #bindpw secret_pass > > ************************************************ > > This file unchanged during the above testing !! > > ************************************************ > > /etc/sudo-ldap.conf: > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > > bindpw secret_pass > > ssl start_tls > > tls_cacertfile /etc/ipa/ca.crt > > tls_checkpeer yes > > bind_timelimit 5 > > timelimit 15 > > uri ldap://chi-infra-idm-p1.linuxcccis.com > > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > QUESTIONS: > > 1) What BINDN account needs to be specified to allow the > > BINDDN/BINDPW to work for SUDO? > > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, > > but SUDO then fails? > > 3) If I leave BINDDN/BINDPW blank, what security risks are being > > introduced by leaving it that way? > > > > > > Anyone on the network can read sudo rules. I guess in theory, the > > attacker might target accounts who are allowed to run sudo rules as a > > gateway for getting elevated privileges on the machine.. > > > From wdh at dds.nl Tue Nov 24 09:25:11 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 24 Nov 2015 10:25:11 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <20151123161626.GR12432@hendrix> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> Message-ID: <56542CF7.7000108@dds.nl> An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 24 09:37:33 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 10:37:33 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <56542CF7.7000108@dds.nl> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> Message-ID: <20151124093733.GY12432@hendrix> On Tue, Nov 24, 2015 at 10:25:11AM +0100, Winfried de Heiden wrote: > Hi all, > > sss_debuglevel 6; in /var/log/sss/sssd_pam.log > > Running as "testuser" crond is denied; perfecr since it is not listed in > the HBAC services. > > [testuser at fedora23-server ~]$ crontab -l > You (testuser) are not allowed to access to (crontab) because of pam > configuration. > > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [accept_fd_handler] (0x0400): > Client connected! > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > Received client version [3]. > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200): > Offered version [3]. > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): > entering pam_cmd_acct_mgmt > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_parse_name_for_domains] > (0x0200): name 'testuser' matched without domain, user is testuser > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_ACCT_MGMT > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > not set > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > testuser > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > crond > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: > cron > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > not set > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 1910 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > name: testuser > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): > Issuing request for [[1]0x561eb0a4b2e0:3:testuser at blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): > Creating request for > [blabla.bla][0x3][BE_REQ_INITGROUPS][1][name=testuser] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_internal_get_send] > (0x0400): Entering request [[2]0x561eb0a4b2e0:3:testuser at blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > Requesting info for [[3]testuser at blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [[4]testuser at blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_ACCT_MGMT > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > blabla.bla > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > testuser > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > crond > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: > cron > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > not set > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 1910 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > name: testuser > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): > Deleting request: [[5]0x561eb0a4b2e0:3:testuser at blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [6 (Permission denied)][blabla.bla] > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [6]: Permission denied. > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27 > (Tue Nov 24 09:54:58 2015) [sssd[pam]] [client_recv] (0x0200): Client > disconnected! > > Now, using su or su - does not show anything in de sssd logs, it looks > like the su service is not using sssd. What could be wrong? Are you running su as an ordinary user or root? What does appear in /var/log/secure when you run su ? Can you show what is the /etc/pam.d/su config and the config of the service that is included from /etc/pam.d/su ? (typically system-auth) > > forgot to mention; allow_all is disabled, checked that 100 times... > > Kind regards, > > Winny > > Op 23-11-15 om 17:16 schreef Jakub Hrozek: > > On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote: > > Hi all, > > I created some hbac rule on freeipa-server 4.1.4 on Fedora 22 > > # ipa hbacrule-show testuser > ? Rule name: testuser > ? Enabled: TRUE > ? Users: testuser > ? Hosts: fedora23-server.blabla.bla > ? Services: sshd > > Hence, " testuser"? is only allowed using sshd on "fedora23-server". No > surprise, this user is not allowed to use "su": > > # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service > su > --------------------- > Access granted: False > > (and yeah sshd is allowed) > > However, doing a "su"? on the fedora23-server.blabla.bla, and giving the > correct password, access is granted. This user is not a member of any > other groups. > HBAC Services like cron or console access are denied correctly since they > are not in the HBAC service list. > > I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several > other ipa-clients (RHEL/CentoOS 6.x, 7.x) > > Shouldn't su or su -l be denied when not listed? > > Yes, and in my testing with a similar rule: > > $ ipa hbacrule-show allow_sshd > Rule name: allow_sshd > Enabled: TRUE > Users: admin > Hosts: client.ipa.test > Services: sshd > > admin can ssh to client.ipa.test but it's not possible to su to admin. > > Please follow [6]https://fedorahosted.org/sssd/wiki/Troubleshooting and check > /var/log/secure and the sssd logs. > > Also, you're not calling su as root, are you? > > References > > Visible links > 1. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla > 2. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla > 3. mailto:testuser at blabla.bla > 4. mailto:testuser at blabla.bla > 5. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla > 6. https://fedorahosted.org/sssd/wiki/Troubleshooting From wdh at dds.nl Tue Nov 24 10:10:11 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 24 Nov 2015 11:10:11 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <20151124093733.GY12432@hendrix> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> Message-ID: <56543783.7050504@dds.nl> An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 24 10:36:25 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 11:36:25 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <56543783.7050504@dds.nl> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> <56543783.7050504@dds.nl> Message-ID: <20151124103625.GB12432@hendrix> On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote: > Hi all, > > Running as an ordinary user, straight from the beginning. > > Is the (default) suid of/usr/bin/su causing this? > ? > Anyway: the info requested: > > /var/log/secure will tell: > Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create > session: Already running in a session > Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened > for user root by testuser(uid=10005) Interesting, there is even no account message at all...not even auth message? > > De pam.d files are from a clean fresh Fedora23 install and > ipa-client-install afterwards: > > /etc/pam.d/su > #%PAM-1.0 > auth??? ??? sufficient??? pam_rootok.so > # Uncomment the following line to implicitly trust users in the "wheel" > group. > #auth??? ??? sufficient??? pam_wheel.so trust use_uid > # Uncomment the following line to require a user to be in the "wheel" > group. > #auth??? ??? required??? pam_wheel.so use_uid > auth??? ??? substack??? system-auth > auth??? ??? include??? ??? postlogin > account??? ??? sufficient??? pam_succeed_if.so uid = 0 use_uid quiet > account??? ??? include??? ??? system-auth ...yet clearly here su includes system_auth unless pam_succeed_if ran (which should only happen if you ran su as root) Just to be sure, can you comment out the pam_succeed_if.so line? > password??? include??? ??? system-auth > session??? ??? include??? ??? system-auth > session??? ??? include??? ??? postlogin > session??? ??? optional??? pam_xauth.so > > /etc/pam.d/postlogin > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > session???? [success=1 default=ignore] pam_succeed_if.so service !~ gdm* > service !~ su* quiet > session???? [default=1]?? pam_lastlog.so nowtmp silent > session???? optional????? pam_lastlog.so silent noupdate showfailed > > /etc/pam.d/system-auth > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth??????? required????? pam_env.so > auth??????? [default=1 success=ok] pam_localuser.so > auth??????? [success=done ignore=ignore default=die] pam_unix.so nullok > try_first_pass > auth??????? requisite???? pam_succeed_if.so uid >= 1000 quiet_success > auth??????? sufficient??? pam_sss.so forward_pass > auth??????? required????? pam_deny.so > > account???? required????? pam_unix.so > account???? sufficient??? pam_localuser.so > account???? sufficient??? pam_succeed_if.so uid < 1000 quiet > account???? [default=bad success=ok user_unknown=ignore] pam_sss.so > account???? required????? pam_permit.so > > password??? requisite???? pam_pwquality.so try_first_pass local_users_only > retry=3 authtok_type= > password??? sufficient??? pam_unix.so sha512 shadow nullok try_first_pass > use_authtok > password??? sufficient??? pam_sss.so use_authtok > password??? required????? pam_deny.so > > session???? optional????? pam_keyinit.so revoke > session???? required????? pam_limits.so > -session???? optional????? pam_systemd.so > session???? optional????? pam_oddjob_mkhomedir.so umask=0077 > session???? [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session???? required????? pam_unix.so > session???? optional????? pam_sss.so > > Op 24-11-15 om 10:37 schreef Jakub Hrozek: > > re you running su as an ordinary user or root? What does appear in > /var/log/secure when you run su ? > > Can you show what is the /etc/pam.d/su config and the config of the > service that is included from /etc/pam.d/su ? (typically system-auth) From jhrozek at redhat.com Tue Nov 24 10:43:27 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 11:43:27 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <56543783.7050504@dds.nl> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> <56543783.7050504@dds.nl> Message-ID: <20151124104327.GC12432@hendrix> On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote: > Hi all, > > Running as an ordinary user, straight from the beginning. > > Is the (default) suid of/usr/bin/su causing this? > ? > Anyway: the info requested: > > /var/log/secure will tell: > Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create > session: Already running in a session > Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened > for user root by testuser(uid=10005) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sorry, I missed this previously. So you're running "su -" as testuser right? That's not hitting SSSD, because the target user is root, so "su" would do: pam_start("su", "root", ...) pam_authenticate(); So what you're seeing is expected. Try su-ing to testuser from another non-root user, it's going to fail. From jhrozek at redhat.com Tue Nov 24 13:04:22 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 14:04:22 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <565450F2.5080407@dds.nl> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> <56543783.7050504@dds.nl> <20151124104327.GC12432@hendrix> <565450F2.5080407@dds.nl> Message-ID: <20151124130422.GD12432@hendrix> On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote: > Hi all, > > [winfried at ipa ~]$ ipa hbacrule-show allow_all > Rule name: allow_all > User category: all > Host category: all > Service category: all > Description: Allow all users to access any host from any host > Enabled: FALSE > > [winfried at ipa ~]$ ipa hbacrule-show testuser > Rule name: testuser > Enabled: TRUE > Users: testuser > Hosts: fedora23-server.blabla.bla > Services: sshd > > [winfried at ipa ~]$ ipa user-show winfried > User login: winfried > First name: Winfried > Last name: de Heiden > Home directory: /home/winfried > Login shell: /bin/bash > etc. .etc. > > [winfried at ipa ~]$ ipa user-show testuser > User login: testuser > First name: test > Last name: user > Home directory: /home/testuser > Login shell: /bin/bash > Email address: testuser at blabla.bla > UID: 10005 > GID: 10005 > Account disabled: False > Password: True > Member of groups: ipausers > Member of HBAC rule: testuser > Kerberos keys available: True > > > > [[testuser at fedora23-server ~]$ su winfried > Wachtwoord: > [winfried at fedora23-server testuser]$ id > UID=10001(winfried) GID=10001(winfried) > groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers) > context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > So yes, I can su to another IPA-user :( > > sssd_pam now shows information, but nothing seems to go wrong... I think you forgot to CC freeipa-users. In this case, can you look into /var/log/secure again and into the domain logs? > > What's happening? > > Winny > > Op 24-11-15 om 11:43 schreef Jakub Hrozek: > >On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote: > >> Hi all, > >> > >> Running as an ordinary user, straight from the beginning. > >> > >> Is the (default) suid of/usr/bin/su causing this? > >> Anyway: the info requested: > >> > >> /var/log/secure will tell: > >> Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create > >> session: Already running in a session > >> Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened > >> for user root by testuser(uid=10005) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >Sorry, I missed this previously. So you're running "su -" as testuser > >right? That's not hitting SSSD, because the target user is root, so "su" > >would do: > > pam_start("su", "root", ...) > > pam_authenticate(); > > > >So what you're seeing is expected. Try su-ing to testuser from another > >non-root user, it's going to fail. > From jstormshak at cccis.com Tue Nov 24 13:45:30 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 24 Nov 2015 13:45:30 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <20151124082507.GU12432@hendrix> References: <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> Message-ID: I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Jakub Hrozek > Date: Tuesday, November 24, 2015 at 2:25 AM To: Rob Crittenden > Cc: Jeffrey Stormshak >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Mon, Nov 23, 2015 at 09:32:52PM -0500, Rob Crittenden wrote: Jeffrey Stormshak wrote: > Jakub/Rob - > Thanks for the feedback. I was finally able to ditch the ?binddn? and > was able to get SSL working upon upgrading the OpenSSL from the 5.5 base > to the one supplied in 5.7 base. The SSL is fully authenticating and > with sudo access. However, I?m riddled by the following item below. > I?m hoping that someone/somewhere encountered this issue and was able > to resolve it using this legacy 5.5. See details provided below. All > thoughts/suggestions are truly appreciated !! > > * > * > > $ id -a > > uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) > > > > $ passwd > > Changing password for user pmoss. > > Enter login(LDAP) password: > > New UNIX password: > > Retype new UNIX password: > > > > LDAP password information update failed: Insufficient access > > Insufficient 'write' privilege to the 'userPassword' attribute of entry > 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. > > > > passwd: Permission denied > > * > * > > # ipa user-show pmoss --all --rights | grep -i userpass -> > attributelevelrights: {u'userpassword': u'swo?, ? > > > pmoss shows *u'userpassword': u'swo'* > > ?swo? translates to ?search,write,delete? > > > Why wouldn?t the above be enough rights to be able to change ?pmoss? > personal password? Thoughts ? Because it is a different part of the tree. Did you use ipa-advise to get the configuration? If so which profile? It looks like that recommends using the compat tree. It's been forever since I've manually configured a RHEL 5 system so I don't know if that is correct or not. Using the compat tree for users and groups (which implies id_provider=ldap, not ipa) is the right thing to do if you also want to use AD trust users on an RHEL-5 client. Otherwise, just use id_provider=ipa (but still point sudo to ou=sudoers) I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a distant memory. rob > *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer* > > Platform Systems | IT Operations Infrastructure > > CCC Information Services, Inc. > > Phone: (312) 229-2552 > > > From: Jakub Hrozek > > Date: Monday, November 23, 2015 at 1:58 AM > To: Jeffrey Stormshak > > Cc: Rob Crittenden >, > "freeipa-users at redhat.com " > > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > > Rob - > Here?s the test configurations/data when I manipulate the > BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux > 5.5. I have three questions below that I would like to get your > comments on or see what you may recommend on this. I?m seriously > perplexed on this as to why its working this way ? Please > advise. Thanks! > ************************************************************** > AUTH successful on login; SUDO fails with the message listed > below !! > ************************************************************** > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > sudo: ldap_sasl_bind_s(): Server is unwilling to perform > > > Looks like the bind didn't finish successfully, can you look into > debugging sudo itself? The debugging changed a bit between releases, but > The sudo documentation would tell you.. > > [sudo] password for mjsmith: > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > ***************************************************** > ***************************************************** > # grep -iv ?#? /etc/ldap.conf > ***************************************************** > base dc=linuxcccis,dc=com > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > bindpw secret_pass > timelimit 15 > bind_timelimit 5 > idle_timelimit 3600 > nss_initgroups_ignoreusers > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > pam_password md5 > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > ************************************************* > User Account AUTH and SUDO works when > commenting both the binddn and bindpw fields !! > ************************************************* > vi /etc/ldap.conf ? Comment these two fields ? > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > #bindpw secret_pass > ************************************************ > This file unchanged during the above testing !! > ************************************************ > /etc/sudo-ldap.conf: > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > bindpw secret_pass > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > bind_timelimit 5 > timelimit 15 > uri ldap://chi-infra-idm-p1.linuxcccis.com > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > QUESTIONS: > 1) What BINDN account needs to be specified to allow the > BINDDN/BINDPW to work for SUDO? > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, > but SUDO then fails? > 3) If I leave BINDDN/BINDPW blank, what security risks are being > introduced by leaving it that way? > > > Anyone on the network can read sudo rules. I guess in theory, the > attacker might target accounts who are allowed to run sudo rules as a > gateway for getting elevated privileges on the machine.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 24 13:51:11 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Nov 2015 14:51:11 +0100 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> Message-ID: <20151124135111.GF12432@hendrix> On Tue, Nov 24, 2015 at 01:45:30PM +0000, Jeffrey Stormshak wrote: > I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? Sorry, I keep forgetting 5.5 doesn't even have sssd. > > The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? You can run ipa-advise on another machine, even on the server. Its output is just an advice, a script you can run. > > I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? > > Jeffrey Stormshak, RHCSA | Sr. Linux Engineer > Platform Systems | IT Operations Infrastructure > CCC Information Services, Inc. > Phone: (312) 229-2552 > > From: Jakub Hrozek > > Date: Tuesday, November 24, 2015 at 2:25 AM > To: Rob Crittenden > > Cc: Jeffrey Stormshak >, "freeipa-users at redhat.com" > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Mon, Nov 23, 2015 at 09:32:52PM -0500, Rob Crittenden wrote: > Jeffrey Stormshak wrote: > > Jakub/Rob - > > Thanks for the feedback. I was finally able to ditch the ?binddn? and > > was able to get SSL working upon upgrading the OpenSSL from the 5.5 base > > to the one supplied in 5.7 base. The SSL is fully authenticating and > > with sudo access. However, I?m riddled by the following item below. > > I?m hoping that someone/somewhere encountered this issue and was able > > to resolve it using this legacy 5.5. See details provided below. All > > thoughts/suggestions are truly appreciated !! > > > > * > > * > > > > $ id -a > > > > uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) > > > > > > > > $ passwd > > > > Changing password for user pmoss. > > > > Enter login(LDAP) password: > > > > New UNIX password: > > > > Retype new UNIX password: > > > > > > > > LDAP password information update failed: Insufficient access > > > > Insufficient 'write' privilege to the 'userPassword' attribute of entry > > 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. > > > > > > > > passwd: Permission denied > > > > * > > * > > > > # ipa user-show pmoss --all --rights | grep -i userpass -> > > attributelevelrights: {u'userpassword': u'swo?, ? > > > > > > pmoss shows *u'userpassword': u'swo'* > > > > ?swo? translates to ?search,write,delete? > > > > > > Why wouldn?t the above be enough rights to be able to change ?pmoss? > > personal password? Thoughts ? > Because it is a different part of the tree. > Did you use ipa-advise to get the configuration? If so which profile? > It looks like that recommends using the compat tree. It's been forever > since I've manually configured a RHEL 5 system so I don't know if that > is correct or not. > > Using the compat tree for users and groups (which implies > id_provider=ldap, not ipa) is the right thing to do if you also want to > use AD trust users on an RHEL-5 client. > > Otherwise, just use id_provider=ipa (but still point sudo to ou=sudoers) > > I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a > distant memory. > rob > > *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer* > > > > Platform Systems | IT Operations Infrastructure > > > > CCC Information Services, Inc. > > > > Phone: (312) 229-2552 > > > > > > From: Jakub Hrozek > > > Date: Monday, November 23, 2015 at 1:58 AM > > To: Jeffrey Stormshak > > > Cc: Rob Crittenden >, > > "freeipa-users at redhat.com " > > > > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > > > On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > > > > Rob - > > Here?s the test configurations/data when I manipulate the > > BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux > > 5.5. I have three questions below that I would like to get your > > comments on or see what you may recommend on this. I?m seriously > > perplexed on this as to why its working this way ? Please > > advise. Thanks! > > ************************************************************** > > AUTH successful on login; SUDO fails with the message listed > > below !! > > ************************************************************** > > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > > sudo: ldap_sasl_bind_s(): Server is unwilling to perform > > > > > > Looks like the bind didn't finish successfully, can you look into > > debugging sudo itself? The debugging changed a bit between releases, but > > The sudo documentation would tell you.. > > > > [sudo] password for mjsmith: > > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > > ***************************************************** > > ***************************************************** > > # grep -iv ?#? /etc/ldap.conf > > ***************************************************** > > base dc=linuxcccis,dc=com > > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > > bindpw secret_pass > > timelimit 15 > > bind_timelimit 5 > > idle_timelimit 3600 > > nss_initgroups_ignoreusers > > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > > pam_password md5 > > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > ************************************************* > > User Account AUTH and SUDO works when > > commenting both the binddn and bindpw fields !! > > ************************************************* > > vi /etc/ldap.conf ? Comment these two fields ? > > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > > #bindpw secret_pass > > ************************************************ > > This file unchanged during the above testing !! > > ************************************************ > > /etc/sudo-ldap.conf: > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > > bindpw secret_pass > > ssl start_tls > > tls_cacertfile /etc/ipa/ca.crt > > tls_checkpeer yes > > bind_timelimit 5 > > timelimit 15 > > uri ldap://chi-infra-idm-p1.linuxcccis.com > > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > > QUESTIONS: > > 1) What BINDN account needs to be specified to allow the > > BINDDN/BINDPW to work for SUDO? > > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, > > but SUDO then fails? > > 3) If I leave BINDDN/BINDPW blank, what security risks are being > > introduced by leaving it that way? > > > > > > Anyone on the network can read sudo rules. I guess in theory, the > > attacker might target accounts who are allowed to run sudo rules as a > > gateway for getting elevated privileges on the machine.. > > > From abokovoy at redhat.com Tue Nov 24 13:57:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Nov 2015 15:57:48 +0200 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> Message-ID: <20151124135748.GM9605@redhat.com> On Tue, 24 Nov 2015, Jeffrey Stormshak wrote: >I went to review the ?ip_provider? and that looks like a ?sssd.conf? >setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in >the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation >here to find any 5.X version of sssd RPM and use that for this >configuration? Sorry, being a newbie on this product realistically >isn?t helping here I?m sure ? > >The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t >exist on the 5.5 distribution as well. Even the version required to >fix the openssl only worked with the 5.7 base version. Am I complete >doomed for 5.5? Cards are stacked for sure. Nonetheless ? ipa-advise is a tool on IPA server that provides recipes how to configure different clients for a typical scenarios involving trust to AD. Read the manual for the tool to get more information. For legacy clients where there is no recent enough SSSD to support trust to AD natively, ipa-advise recommends using schema compatibility plugin to expose both IPA and AD users under same LDAP tree. This is what you see in cn=users,cn=compat,dc=example,dc=com. If you see cn=compat in the LDAP base DN, you know you are looking into the compatibility tree. Compatibility tree is handled by a special plugin which combines data from the primary IPA tree (cn=accounts,dc=example,dc=com) and from SSSD on IPA server. It also exposes ou=SUDOers subtree to allow SUDO application to work with sudo rules stored in IPA LDAP (they are not in the same format as SUDO itself expects, thus _compatibility_ subtree). >I feel so close though? Auth and Sudo works on 5.5 but something as >simple as users changing passwords seems so simple to provide? Finally, password changes are not supported in cn=compat subtree. This is simply not implemented by schema compatibility plugin. You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. If you don't need integration with Active Directory, change LDAP base DN in your configuration to cn=accounts,dc=example,dc=com, to point your clients to the primary IPA subtree where all users and groups are available. That subtree is the main one and we do support password changes for DNs in it. -- / Alexander Bokovoy From wdh at dds.nl Tue Nov 24 14:32:07 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 24 Nov 2015 15:32:07 +0100 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <20151124130422.GD12432@hendrix> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> <56543783.7050504@dds.nl> <20151124104327.GC12432@hendrix> <565450F2.5080407@dds.nl> <20151124130422.GD12432@hendrix> Message-ID: <565474E7.6070900@dds.nl> Hi all, The problem is clear, there is a misunderstanding of the service "su" and "su-l", this is about the target users. Hence; su - to user winfried is allowed since su and su-l are added to the hbac service list of this user. This looks a bit strange from the ui perspective, all other HBAC services are what this user is allow to do; "su" and "su-l" defines that OTHER user may become this user by using su. A bit strange, but this is how is works. Anyone disagree? Winny Op 24-11-15 om 14:04 schreef Jakub Hrozek: > On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote: >> Hi all, >> >> [winfried at ipa ~]$ ipa hbacrule-show allow_all >> Rule name: allow_all >> User category: all >> Host category: all >> Service category: all >> Description: Allow all users to access any host from any host >> Enabled: FALSE >> >> [winfried at ipa ~]$ ipa hbacrule-show testuser >> Rule name: testuser >> Enabled: TRUE >> Users: testuser >> Hosts: fedora23-server.blabla.bla >> Services: sshd >> >> [winfried at ipa ~]$ ipa user-show winfried >> User login: winfried >> First name: Winfried >> Last name: de Heiden >> Home directory: /home/winfried >> Login shell: /bin/bash >> etc. .etc. >> >> [winfried at ipa ~]$ ipa user-show testuser >> User login: testuser >> First name: test >> Last name: user >> Home directory: /home/testuser >> Login shell: /bin/bash >> Email address: testuser at blabla.bla >> UID: 10005 >> GID: 10005 >> Account disabled: False >> Password: True >> Member of groups: ipausers >> Member of HBAC rule: testuser >> Kerberos keys available: True >> >> >> >> [[testuser at fedora23-server ~]$ su winfried >> Wachtwoord: >> [winfried at fedora23-server testuser]$ id >> UID=10001(winfried) GID=10001(winfried) >> groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers) >> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> >> So yes, I can su to another IPA-user :( >> >> sssd_pam now shows information, but nothing seems to go wrong... > I think you forgot to CC freeipa-users. > > In this case, can you look into /var/log/secure again and into the > domain logs? > >> What's happening? >> >> Winny >> >> Op 24-11-15 om 11:43 schreef Jakub Hrozek: >>> On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote: >>>> Hi all, >>>> >>>> Running as an ordinary user, straight from the beginning. >>>> >>>> Is the (default) suid of/usr/bin/su causing this? >>>> Anyway: the info requested: >>>> >>>> /var/log/secure will tell: >>>> Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create >>>> session: Already running in a session >>>> Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened >>>> for user root by testuser(uid=10005) >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Sorry, I missed this previously. So you're running "su -" as testuser >>> right? That's not hitting SSSD, because the target user is root, so "su" >>> would do: >>> pam_start("su", "root", ...) >>> pam_authenticate(); >>> >>> So what you're seeing is expected. Try su-ing to testuser from another >>> non-root user, it's going to fail. From pdomineaux at gmail.com Tue Nov 24 14:33:38 2015 From: pdomineaux at gmail.com (Domineaux Philippe) Date: Tue, 24 Nov 2015 15:33:38 +0100 Subject: [Freeipa-users] Active Directory Integration and limitations In-Reply-To: <1448292999.7892.22.camel@redhat.com> References: <1448292999.7892.22.camel@redhat.com> Message-ID: Thank you for your answer but ... 2015-11-23 16:36 GMT+01:00 Simo Sorce : > On Wed, 2015-11-18 at 11:46 +0100, Domineaux Philippe wrote: > > Here is my environment : > > > > 1 Windows Domain > > Windows workstations > > Windows servers > > Multiple linux domains > > Linux workstations > > Linux servers > > > > Here is my goal : > > > > All users are centralized in the Active Directory. > > Users will authenticate on linux workstations with their AD accounts ( > > using POSIX attributes). > > Linux workstations must have access to NFS shares on Linux servers. > > Hi Domineaux, > you should look into setting up FreeIPA with a trust relationship to the > Windows Domain. > > That's already the case, I use the Trust relationship with POSIX attributes. > > What are the limitations ? > > It is hard to say what kind of limitations you are interested into, when > we trust AD, then AD users can access Linux machines, one limitation (if > you think it is a limitation) is that AD users will have fully qualified > names on the host (example: user at ad.example.com) and not just flat names > to avoid name clashes between ipa users, local users and AD users. > > I'm ok with the use of fully qualified names, I use it to log in to my workstations. > > Windows users equals ipa users in term of services ? > > Yes. > > > Do I have to configure kerberos to also join directly the Windows > Kerberos > > Realm, > > or will IPA do the job to ask Windows server ? > > If you set up a trust between servers all is taken care of for you wrt > clients. > > > in etc/krb5.conf : > > > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > > > [libdefaults] > > default_realm = IPA.ORG > > dns_lookup_realm = true > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > udp_preference_limit = 0 > > default_ccache_name = KEYRING:persistent:%{uid} > > canonicalize = yes > > allow_weak_crypto = true > > > > [realms] > > IPA.ORG = { > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > auth_to_local = RULE:[1:$1@ > > $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ > > auth_to_local = DEFAULT > > > > } > > > > ### IS THIS NECESSARY > > WINDOMAIN.LOCAL = { > > kdc = srvadipa.windomain.local > > admin_server = srvadipa.windomain.local > > } > > > > > > [domain_realm] > > .ipa.org = IPA.ORG > > ipa.org = IPA.ORG > > > > ### IS THIS NECESSARY > > > > .windomain.local = WINDOMAIN.LOCAL > > windomain.local = WINDOMAIN.LOCAL > > It depends on what client you are using, older RHEL may need this, newer > ones have an include directory in krb5.conf and sssd generates > appropriate configuration automatically based on server configuration. > > > Is the bug in libnfsidmap still active and prevents Windows users to > access > > to NFS4 krb5 secured shared folder ? > > I am not sure what bug you refer to. You may need to configure nfs > client nfs idmap, but I am not aware of bugs that will prevent it from > working right if properly configured. > > The bug specified below return me this on the NFS server (part of the ipa domain ) : Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "650800001" -> name "testipa at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "650800001" -> name "testipa at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "65534" -> name "nfsnobody at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "65534" -> name "nfsnobody at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "10002" -> name "adipa at windomain.local@ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: calling nsswitch->uid_to_name Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "10047" -> name "posix_users at windomain.local@ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "0" -> name "root at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "0" -> name "root at ipa.org" Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: nsswitch->*uid_to_name returned 0* Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: *final return value is 0* Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: Server : (user) id "650800001" -> name "testipa at ipa.org" So it seems that for a native ipa user ( in my case testipa ) , the uid is return but for an AD user, it returns me zero. The result is that when I am logged on a workstation using an AD account I see nfs shares with nobody attributes. Specifically you may want to *not* try to consult LDAP from idmap, but > use a regex to transform the windows realm from upper case to lowercase > and then just use the getpwnam interface. > > As you can see on my krb5.conf there is already a regex for the ipa realm = auth_to_local = RULE:[1:$1@ > $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ > Simo. > > > I currently have > > > > bug here: > > https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html > > -- > > 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 > > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 24 14:58:07 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Nov 2015 16:58:07 +0200 Subject: [Freeipa-users] hbac service allowed despite not listed In-Reply-To: <565474E7.6070900@dds.nl> References: <565336F3.1070402@dds.nl> <20151123161626.GR12432@hendrix> <56542CF7.7000108@dds.nl> <20151124093733.GY12432@hendrix> <56543783.7050504@dds.nl> <20151124104327.GC12432@hendrix> <565450F2.5080407@dds.nl> <20151124130422.GD12432@hendrix> <565474E7.6070900@dds.nl> Message-ID: <20151124145807.GN9605@redhat.com> On Tue, 24 Nov 2015, Winfried de Heiden wrote: > >Hi all, > >The problem is clear, there is a misunderstanding of the service "su" >and "su-l", this is about the target users. Hence; su - to user >winfried is allowed since su and su-l are added to the hbac service >list of this user. > >This looks a bit strange from the ui perspective, all other HBAC >services are what this user is allow to do; "su" and "su-l" defines >that OTHER user may become this user by using su. > >A bit strange, but this is how is works. Anyone disagree? Consider the fact that HBAC names are names of PAM services used by applications. If an application uses PAM, it specifies name of own configuration file relative to /etc/pam.d toPAM API. For 'su' utility look into its manual page, section FILES: FILES /etc/pam.d/su default PAM configuration file /etc/pam.d/su-l PAM configuration file if --login is specified /etc/default/su command specific logindef config file /etc/login.defs global logindef config file 'su' utility uses two different PAM names for different modes of operation. Therefore, when defining HBAC rules for 'su' you need to take into account both PAM services and decide what you want to do with them. > >Winny > > > > > >Op 24-11-15 om 14:04 schreef Jakub Hrozek: >>On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote: >>>Hi all, >>> >>>[winfried at ipa ~]$ ipa hbacrule-show allow_all >>> Rule name: allow_all >>> User category: all >>> Host category: all >>> Service category: all >>> Description: Allow all users to access any host from any host >>> Enabled: FALSE >>> >>>[winfried at ipa ~]$ ipa hbacrule-show testuser >>> Rule name: testuser >>> Enabled: TRUE >>> Users: testuser >>> Hosts: fedora23-server.blabla.bla >>> Services: sshd >>> >>>[winfried at ipa ~]$ ipa user-show winfried >>> User login: winfried >>> First name: Winfried >>> Last name: de Heiden >>> Home directory: /home/winfried >>> Login shell: /bin/bash >>>etc. .etc. >>> >>>[winfried at ipa ~]$ ipa user-show testuser >>> User login: testuser >>> First name: test >>> Last name: user >>> Home directory: /home/testuser >>> Login shell: /bin/bash >>> Email address: testuser at blabla.bla >>> UID: 10005 >>> GID: 10005 >>> Account disabled: False >>> Password: True >>> Member of groups: ipausers >>> Member of HBAC rule: testuser >>> Kerberos keys available: True >>> >>> >>> >>>[[testuser at fedora23-server ~]$ su winfried >>>Wachtwoord: >>>[winfried at fedora23-server testuser]$ id >>>UID=10001(winfried) GID=10001(winfried) >>>groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers) >>>context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>> >>>So yes, I can su to another IPA-user :( >>> >>>sssd_pam now shows information, but nothing seems to go wrong... >>I think you forgot to CC freeipa-users. >> >>In this case, can you look into /var/log/secure again and into the >>domain logs? >> >>>What's happening? >>> >>>Winny >>> >>>Op 24-11-15 om 11:43 schreef Jakub Hrozek: >>>>On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote: >>>>> Hi all, >>>>> >>>>> Running as an ordinary user, straight from the beginning. >>>>> >>>>> Is the (default) suid of/usr/bin/su causing this? >>>>> Anyway: the info requested: >>>>> >>>>> /var/log/secure will tell: >>>>> Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create >>>>> session: Already running in a session >>>>> Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened >>>>> for user root by testuser(uid=10005) >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >>>>Sorry, I missed this previously. So you're running "su -" as testuser >>>>right? That's not hitting SSSD, because the target user is root, so "su" >>>>would do: >>>> pam_start("su", "root", ...) >>>> pam_authenticate(); >>>> >>>>So what you're seeing is expected. Try su-ing to testuser from another >>>>non-root user, it's going to fail. > >-- >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 -- / Alexander Bokovoy From jstormshak at cccis.com Tue Nov 24 15:01:50 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 24 Nov 2015 15:01:50 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564B4CEB.7040206@redhat.com> <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> Message-ID: Went after the suggestion and sorry for the length of the sssd.conf, but I do want to ensure I?m not making the wrong option selection mistakes. The same error message is being produced. Additionally, this client and IDM server has no integration into AD at this point. Just trying to get IDM working on the legacy client. Error and configuration provided below: [mjsmith at chi-infra-idm-client2 ~]$ passwd Changing password for user mjsmith. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Insufficient access Insufficient 'write' privilege to the 'userPassword' attribute of entry 'uid=mjsmith,cn=users,cn=compat,dc=linuxcccis,dc=com'. passwd: Permission denied # grep -iv '#' ./sssd.conf [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam ; domains = LOCAL,LDAP domains = LINUXCCCIS.COM [nss] ;filter_groups = root ;filter_users = root ;reconnection_retries = 3 ; entry_cache_nowait_percentage = 300 [pam] ;reconnection_retries = 3 ; [domain/LOCAL] ; description = LOCAL Users domain ; id_provider = local ; enumerate = true ; min_id = 500 ; max_id = 999 ; [domain/LDAP] ; id_provider = ldap ; auth_provider = ldap ; ldap_schema = rfc2307 ; ldap_uri = ldap://ldap.mydomain.org ; ldap_search_base = dc=mydomain,dc=org ; ldap_tls_reqcert = demand ; cache_credentials = true ; enumerate = False ; entry_cache_timeout = 5400 ; [domain/AD] ; description = LDAP domain with AD server ; enumerate = false ; min_id = 1000 ; ; id_provider = ldap ; auth_provider = ldap ; ldap_uri = ldap://your.ad.server.com ; ldap_schema = rfc2307bis ; ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com ; ldap_default_authtok_type = password ; ldap_default_authtok = YOUR_PASSWORD ; ldap_user_object_class = person ; ldap_user_name = msSFU30Name ; ldap_user_uid_number = msSFU30UidNumber ; ldap_user_gid_number = msSFU30GidNumber ; ldap_user_home_directory = msSFU30HomeDirectory ; ldap_user_shell = msSFU30LoginShell ; ldap_user_principal = userPrincipalName ; ldap_group_object_class = group ; ldap_group_name = msSFU30Name ; ldap_group_gid_number = msSFU30GidNumber ; ldap_force_upper_case_realm = True [domain/LINUXCCCIS.COM] ;cache_credentials = True ;krb5_store_password_if_offline = True ipa_domain = LINUXCCCIS.COM id_provider = ldap auth_provider = ldap access_provider = ldap chpass_provider = ldap ;ipa_dyndns_update = True ipa_server = _srv_, chi-infra-idm-p1.linuxcccis.com ;ldap_tls_cacert = /var/tmp/ca.crt ldap_tls_cacert = /etc/openldap/cacerts/authconfig_downloads.pem ;debug_level = 6 From: Jeffrey Stormshak Sent: Tuesday, November 24, 2015 7:46 AM To: Jakub Hrozek; Rob Crittenden Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Jakub Hrozek > Date: Tuesday, November 24, 2015 at 2:25 AM To: Rob Crittenden > Cc: Jeffrey Stormshak >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Mon, Nov 23, 2015 at 09:32:52PM -0500, Rob Crittenden wrote: Jeffrey Stormshak wrote: > Jakub/Rob - > Thanks for the feedback. I was finally able to ditch the ?binddn? and > was able to get SSL working upon upgrading the OpenSSL from the 5.5 base > to the one supplied in 5.7 base. The SSL is fully authenticating and > with sudo access. However, I?m riddled by the following item below. > I?m hoping that someone/somewhere encountered this issue and was able > to resolve it using this legacy 5.5. See details provided below. All > thoughts/suggestions are truly appreciated !! > > * > * > > $ id -a > > uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin) > > > > $ passwd > > Changing password for user pmoss. > > Enter login(LDAP) password: > > New UNIX password: > > Retype new UNIX password: > > > > LDAP password information update failed: Insufficient access > > Insufficient 'write' privilege to the 'userPassword' attribute of entry > 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'. > > > > passwd: Permission denied > > * > * > > # ipa user-show pmoss --all --rights | grep -i userpass -> > attributelevelrights: {u'userpassword': u'swo?, ? > > > pmoss shows *u'userpassword': u'swo'* > > ?swo? translates to ?search,write,delete? > > > Why wouldn?t the above be enough rights to be able to change ?pmoss? > personal password? Thoughts ? Because it is a different part of the tree. Did you use ipa-advise to get the configuration? If so which profile? It looks like that recommends using the compat tree. It's been forever since I've manually configured a RHEL 5 system so I don't know if that is correct or not. Using the compat tree for users and groups (which implies id_provider=ldap, not ipa) is the right thing to do if you also want to use AD trust users on an RHEL-5 client. Otherwise, just use id_provider=ipa (but still point sudo to ou=sudoers) I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a distant memory. rob > *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer* > > Platform Systems | IT Operations Infrastructure > > CCC Information Services, Inc. > > Phone: (312) 229-2552 > > > From: Jakub Hrozek > > Date: Monday, November 23, 2015 at 1:58 AM > To: Jeffrey Stormshak > > Cc: Rob Crittenden >, > "freeipa-users at redhat.com " > > > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question > > On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote: > > Rob - > Here?s the test configurations/data when I manipulate the > BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux > 5.5. I have three questions below that I would like to get your > comments on or see what you may recommend on this. I?m seriously > perplexed on this as to why its working this way ? Please > advise. Thanks! > ************************************************************** > AUTH successful on login; SUDO fails with the message listed > below !! > ************************************************************** > [mjsmith at chi-infra-idm-client2 ~]$ sudo -l > sudo: ldap_sasl_bind_s(): Server is unwilling to perform > > > Looks like the bind didn't finish successfully, can you look into > debugging sudo itself? The debugging changed a bit between releases, but > The sudo documentation would tell you.. > > [sudo] password for mjsmith: > Sorry, user mjsmith may not run sudo on chi-infra-idm-client2. > ***************************************************** > ***************************************************** > # grep -iv ?#? /etc/ldap.conf > ***************************************************** > base dc=linuxcccis,dc=com > uri ldap://chi-infra-idm-p1.linuxcccis.com/ > binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > bindpw secret_pass > timelimit 15 > bind_timelimit 5 > idle_timelimit 3600 > nss_initgroups_ignoreusers > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > pam_password md5 > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > ************************************************* > User Account AUTH and SUDO works when > commenting both the binddn and bindpw fields !! > ************************************************* > vi /etc/ldap.conf ? Comment these two fields ? > #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com > #bindpw secret_pass > ************************************************ > This file unchanged during the above testing !! > ************************************************ > /etc/sudo-ldap.conf: > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com > bindpw secret_pass > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > bind_timelimit 5 > timelimit 15 > uri ldap://chi-infra-idm-p1.linuxcccis.com > sudoers_base ou=SUDOers,dc=linuxcccis,dc=com > QUESTIONS: > 1) What BINDN account needs to be specified to allow the > BINDDN/BINDPW to work for SUDO? > 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, > but SUDO then fails? > 3) If I leave BINDDN/BINDPW blank, what security risks are being > introduced by leaving it that way? > > > Anyone on the network can read sudo rules. I guess in theory, the > attacker might target accounts who are allowed to run sudo rules as a > gateway for getting elevated privileges on the machine.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Nov 24 15:07:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Nov 2015 17:07:45 +0200 Subject: [Freeipa-users] Active Directory Integration and limitations In-Reply-To: References: <1448292999.7892.22.camel@redhat.com> Message-ID: <20151124150745.GO9605@redhat.com> On Tue, 24 Nov 2015, Domineaux Philippe wrote: >So it seems that for a native ipa user ( in my case testipa ) , the uid is >return but for an AD user, it returns me zero. >The result is that when I am logged on a workstation using an AD account I >see nfs shares with nobody attributes. Show your nsfidmap configuration, /etc/idmapd.conf. Are you using SSSD plugin for translation? [Translation] Method = sss GSS-Methods = sss >Specifically you may want to *not* try to consult LDAP from idmap, but >> use a regex to transform the windows realm from upper case to lowercase >> and then just use the getpwnam interface. >> >> >As you can see on my krb5.conf there is already a regex for the ipa realm = > >auth_to_local = RULE:[1:$1@$0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ This is irrelevant for nfsidmap. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 24 15:10:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Nov 2015 17:10:37 +0200 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> Message-ID: <20151124151037.GP9605@redhat.com> On Tue, 24 Nov 2015, Jeffrey Stormshak wrote: >Went after the suggestion and sorry for the length of the sssd.conf, >but I do want to ensure I?m not making the wrong option selection >mistakes. The same error message is being produced. Additionally, >this client and IDM server has no integration into AD at this point. >Just trying to get IDM working on the legacy client. > >Error and configuration provided below: >[mjsmith at chi-infra-idm-client2 ~]$ passwd >Changing password for user mjsmith. >Enter login(LDAP) password: >New UNIX password: >Retype new UNIX password: >LDAP password information update failed: Insufficient access >Insufficient 'write' privilege to the 'userPassword' attribute of entry 'uid=mjsmith,cn=users,cn=compat,dc=linuxcccis,dc=com'. >passwd: Permission denied As long as you are trying to change password of a user identified by LDAP DN under cn=compat,dc=linuxcccis,dc=com, you will fail. Read my other email in the same thread. -- / Alexander Bokovoy From jstormshak at cccis.com Tue Nov 24 22:39:49 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 24 Nov 2015 22:39:49 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: <20151124135748.GM9605@redhat.com> References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> <20151124135748.GM9605@redhat.com> Message-ID: Alex - Thank you for the details!! For right now, I?m using the IPA Server as a standalone Linux domain controller/server without any AD integration. This allows testing to prove that this could work with a large number of 5.5 clients in the enterprise to date. On the question being proposed ? You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. ANSWER: Yes. I?m trying to achieve full integration with AD but I?m only at the point where I started testing this in a standalone Linux mode. I was trying to see if these legacy 5.5 clients were even possible to configure and to work here as specified. I?ll review the IPA tools for better understanding here. Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Alexander Bokovoy > Date: Tuesday, November 24, 2015 at 7:57 AM To: Jeffrey Stormshak > Cc: Jakub Hrozek >, Rob Crittenden >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Tue, 24 Nov 2015, Jeffrey Stormshak wrote: I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? ipa-advise is a tool on IPA server that provides recipes how to configure different clients for a typical scenarios involving trust to AD. Read the manual for the tool to get more information. For legacy clients where there is no recent enough SSSD to support trust to AD natively, ipa-advise recommends using schema compatibility plugin to expose both IPA and AD users under same LDAP tree. This is what you see in cn=users,cn=compat,dc=example,dc=com. If you see cn=compat in the LDAP base DN, you know you are looking into the compatibility tree. Compatibility tree is handled by a special plugin which combines data from the primary IPA tree (cn=accounts,dc=example,dc=com) and from SSSD on IPA server. It also exposes ou=SUDOers subtree to allow SUDO application to work with sudo rules stored in IPA LDAP (they are not in the same format as SUDO itself expects, thus _compatibility_ subtree). I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? Finally, password changes are not supported in cn=compat subtree. This is simply not implemented by schema compatibility plugin. You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. If you don't need integration with Active Directory, change LDAP base DN in your configuration to cn=accounts,dc=example,dc=com, to point your clients to the primary IPA subtree where all users and groups are available. That subtree is the main one and we do support password changes for DNs in it. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From harenberg at physik.uni-wuppertal.de Wed Nov 25 08:28:09 2015 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Wed, 25 Nov 2015 09:28:09 +0100 Subject: [Freeipa-users] freeipa client on Linux Mint? Message-ID: <56557119.9070203@physik.uni-wuppertal.de> Dear all, just wanna ask if anyone has successfully managed to get the freeipa client to work on a recent Linux Mint. While Mint should be more or less compatible to Ubuntu 14.04, and I had no problems getting it to run on Ubuntu, I failed to get it working on Mint. The installation process went smoothly and not different to those on Ubuntu. I just found libpam-sss not being installed as dependency. Kerberos seems to work okay as well, I can get a Kerberos token. But the user names are not resolved, all IPA users are unknown. I already checked /etc/nsswitch.conf and /etc/pam.d/*, but could not found a real difference which could explain that. What I found is a possibility https://sites.google.com/site/fossvi/home/howto-freeipa-client-install-linux-mint-ubuntu which seem to work, BUT this is getting the users through LDAP not sssd. That was not needed for Ubuntu. I tried to use both the provided packages as well as the ppa repositories for both sssd and freeipa-client. I raised the log level for sssd but even with a high log level I couldn't identify an error. Best regards, Torsten -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> <> Bergische Universitaet <> <> FB C - Physik Tel.: +49 (0)202 439-3521 <> <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> <> 42097 Wuppertal <> <> <> <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> From d.korittki at mittwald.de Wed Nov 25 09:18:13 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Wed, 25 Nov 2015 10:18:13 +0100 Subject: [Freeipa-users] freeipa client on Linux Mint? In-Reply-To: <56557119.9070203@physik.uni-wuppertal.de> References: <56557119.9070203@physik.uni-wuppertal.de> Message-ID: <56557CD5.1010704@mittwald.de> Am 25.11.2015 um 09:28 schrieb Torsten Harenberg: > Dear all, > > just wanna ask if anyone has successfully managed to get the freeipa > client to work on a recent Linux Mint. > > While Mint should be more or less compatible to Ubuntu 14.04, and I had > no problems getting it to run on Ubuntu, I failed to get it working on Mint. > > The installation process went smoothly and not different to those on > Ubuntu. I just found libpam-sss not being installed as dependency. > > Kerberos seems to work okay as well, I can get a Kerberos token. > > But the user names are not resolved, all IPA users are unknown. > > I already checked /etc/nsswitch.conf and /etc/pam.d/*, but could not > found a real difference which could explain that. For me it sounds like NSS can't resolve IPA users, which is done by libnss_sss package (on Debian, but should be the same for Ubuntu/Mint). If I remember correctly libnss_sss is no hard dependency on SSSD, so maybe it didn't get installed along with SSSD. > > What I found is a possibility > > https://sites.google.com/site/fossvi/home/howto-freeipa-client-install-linux-mint-ubuntu > > which seem to work, BUT this is getting the users through LDAP not sssd. > That was not needed for Ubuntu. > > I tried to use both the provided packages as well as the ppa > repositories for both sssd and freeipa-client. > > I raised the log level for sssd but even with a high log level I > couldn't identify an error. > > Best regards, > > Torsten > > From lslebodn at redhat.com Wed Nov 25 09:26:47 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 25 Nov 2015 10:26:47 +0100 Subject: [Freeipa-users] freeipa client on Linux Mint? In-Reply-To: <56557CD5.1010704@mittwald.de> References: <56557119.9070203@physik.uni-wuppertal.de> <56557CD5.1010704@mittwald.de> Message-ID: <20151125092646.GC24040@mail.corp.redhat.com> On (25/11/15 10:18), Dominik Korittki wrote: > > >Am 25.11.2015 um 09:28 schrieb Torsten Harenberg: >>Dear all, >> >>just wanna ask if anyone has successfully managed to get the freeipa >>client to work on a recent Linux Mint. >> >>While Mint should be more or less compatible to Ubuntu 14.04, and I had >>no problems getting it to run on Ubuntu, I failed to get it working on Mint. >> >>The installation process went smoothly and not different to those on >>Ubuntu. I just found libpam-sss not being installed as dependency. >> >>Kerberos seems to work okay as well, I can get a Kerberos token. >> >>But the user names are not resolved, all IPA users are unknown. >> >>I already checked /etc/nsswitch.conf and /etc/pam.d/*, but could not >>found a real difference which could explain that. > >For me it sounds like NSS can't resolve IPA users, which is done by >libnss_sss package (on Debian, but should be the same for Ubuntu/Mint). >If I remember correctly libnss_sss is no hard dependency on SSSD, >so maybe it didn't get installed along with SSSD. > It is just recomended package. http://anonscm.debian.org/cgit/pkg-sssd/sssd.git/tree/debian/control?h=ubuntu lines 79 .. 82 Package: sssd-common Architecture: any Depends: python, python-sss, ${misc:Depends}, ${shlibs:Depends} Recommends: bind9-host, libnss-sss, libpam-sss, libsss-sudo LS From harenberg at physik.uni-wuppertal.de Wed Nov 25 09:34:08 2015 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Wed, 25 Nov 2015 10:34:08 +0100 Subject: [Freeipa-users] freeipa client on Linux Mint? In-Reply-To: <56557CD5.1010704@mittwald.de> References: <56557119.9070203@physik.uni-wuppertal.de> <56557CD5.1010704@mittwald.de> Message-ID: <56558090.1020801@physik.uni-wuppertal.de> Am 25.11.15 um 10:18 schrieb Dominik Korittki: > > For me it sounds like NSS can't resolve IPA users, which is done by > libnss_sss package (on Debian, but should be the same for Ubuntu/Mint). > If I remember correctly libnss_sss is no hard dependency on SSSD, > so maybe it didn't get installed along with SSSD. thanks Dominik, meanwhile I found that two packages were missing: libpam-sss and libnss-sss After installing those, it works :) Hope this is helpful for someone else. Best regards, Torsten -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> <> Bergische Universitaet <> <> FB C - Physik Tel.: +49 (0)202 439-3521 <> <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> <> 42097 Wuppertal <> <> <> <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> From wouter.hummelink at kpn.com Wed Nov 25 12:42:28 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Wed, 25 Nov 2015 12:42:28 +0000 Subject: [Freeipa-users] CA Certificate Profile Message-ID: <2CA71D6C07ADB544847562573DC6BF0618549E9A@CPEMS-KPN309.KPNCNL.LOCAL> Hello, For one of my customer projects I need server certificates that have an OU component in de the subject. I tried making a certificate profile that is identical to the default caIPAServiceCert except for the first section. I changed the constraint to include OU and the default to include an OU, however that doesn't appear to be a valid field. policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl policyset.serverCertSet.1.constraint.name=Subject Name Constraint policyset.serverCertSet.1.constraint.params.accept=true policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,OU=[^,],.+ policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl policyset.serverCertSet.1.default.name=Subject Name Default policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,OU=$request.req_subject_name.ou$,O=LINUX.TEST.INFRA.LOCAL I can see the CSR that comes into pki include the OU field when requested like following. ipa-getcert request -I test -k /etc/pki/tls/certs/server.key -f /etc/pki/tls/certs/server.cert -N "CN=$(hostname -f),OU=Test,O=LINUX.TEST.INFRA.LOCAL" -K host/$(hostname -f) -w -T KPNWebhostingServiceCert The debug log however doesn't show a key like request.req_subject_name.ou, and results in a nasty error on the certmonger side: Request ID 'test': status: CA_UNREACHABLE ca-error: Server at https://ipaserver.ipa.local/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: unknown(3) (Request Rejected - {0})). stuck: no key pair storage: type=FILE,location='/etc/pki/tls/certs/server.key' certificate: type=FILE,location='/etc/pki/tls/certs/server.cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Met vriendelijke groet, Wouter Hummelink Cloud Engineer [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] KPN IT Solutions Platform Organisation Cloud Services Mail: wouter.hummelink at kpn.com Telefoon: +31 (0)6 1288 2447 [cid:image002.png at 01D0DA65.706AE4B0] P Save Paper - Do you really need to print this e-mail? ********************************************************************************************************************************************************* KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. ********************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2045 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49569 bytes Desc: image002.png URL: From giorgio at di.unimi.it Wed Nov 25 17:58:08 2015 From: giorgio at di.unimi.it (Giorgio Biacchi) Date: Wed, 25 Nov 2015 18:58:08 +0100 Subject: [Freeipa-users] Question about UPN suffixes in AD trust Message-ID: <5655F6B0.7020900@di.unimi.it> Hello list, can someone please clarify which configuration steps are needed to make FreeIPA aware of additionals UPN suffixes defined on AD? In my test environment I have a two way trust between the AD (Win 2012 R2) and IPA (Fedora 23) servers. On the AD there are 2 UPNs and I need to authenticate users with accounts based on those 2 UPNs via IPA against the AD. I'm using FreeIPA 4.2.3-1 for FC23 but I'm still unable to make it work in this scenario although the bug described here https://fedorahosted.org/freeipa/ticket/3559 is now fixed. Thanks in advance for any kind reply. -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 From abokovoy at redhat.com Wed Nov 25 18:51:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Nov 2015 20:51:32 +0200 Subject: [Freeipa-users] Question about UPN suffixes in AD trust In-Reply-To: <5655F6B0.7020900@di.unimi.it> References: <5655F6B0.7020900@di.unimi.it> Message-ID: <20151125185132.GT9605@redhat.com> On Wed, 25 Nov 2015, Giorgio Biacchi wrote: >Hello list, >can someone please clarify which configuration steps are needed to make FreeIPA >aware of additionals UPN suffixes defined on AD? > >In my test environment I have a two way trust between the AD (Win 2012 R2) and >IPA (Fedora 23) servers. On the AD there are 2 UPNs and I need to authenticate >users with accounts based on those 2 UPNs via IPA against the AD. > >I'm using FreeIPA 4.2.3-1 for FC23 but I'm still unable to make it work in this >scenario although the bug described here >https://fedorahosted.org/freeipa/ticket/3559 is now fixed. > >Thanks in advance for any kind reply. FreeIPA currently only picks up primary user names (sAMAccountName). To pull UPNs for trusted domains we need to use a bit different method to retrieve trust topology information which we were unable to do before 4.2. This is in the plan for 4.4 I think. The ticket you mentioned is enabler but it needs appropriate information in the trust topology to compare realms/UPNs. -- / Alexander Bokovoy From ftweedal at redhat.com Thu Nov 26 04:03:10 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 26 Nov 2015 14:03:10 +1000 Subject: [Freeipa-users] CA Certificate Profile In-Reply-To: <2CA71D6C07ADB544847562573DC6BF0618549E9A@CPEMS-KPN309.KPNCNL.LOCAL> References: <2CA71D6C07ADB544847562573DC6BF0618549E9A@CPEMS-KPN309.KPNCNL.LOCAL> Message-ID: <20151126040310.GE23644@dhcp-40-8.bne.redhat.com> On Wed, Nov 25, 2015 at 12:42:28PM +0000, wouter.hummelink at kpn.com wrote: > Hello, > > For one of my customer projects I need server certificates that have an OU component in de the subject. I tried making a certificate profile that is identical to the default caIPAServiceCert except for the first section. I changed the constraint to include OU and the default to include an OU, however that doesn't appear to be a valid field. > > policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl > policyset.serverCertSet.1.constraint.name=Subject Name Constraint > policyset.serverCertSet.1.constraint.params.accept=true > policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,OU=[^,],.+ > policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl > policyset.serverCertSet.1.default.name=Subject Name Default > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,OU=$request.req_subject_name.ou$,O=LINUX.TEST.INFRA.LOCAL > > I can see the CSR that comes into pki include the OU field when requested like following. > > ipa-getcert request -I test -k /etc/pki/tls/certs/server.key -f /etc/pki/tls/certs/server.cert -N "CN=$(hostname -f),OU=Test,O=LINUX.TEST.INFRA.LOCAL" -K host/$(hostname -f) -w -T KPNWebhostingServiceCert > > The debug log however doesn't show a key like request.req_subject_name.ou, and results in a nasty error on the certmonger side: > Request ID 'test': > status: CA_UNREACHABLE > ca-error: Server at https://ipaserver.ipa.local/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: unknown(3) (Request Rejected - {0})). > stuck: no > key pair storage: type=FILE,location='/etc/pki/tls/certs/server.key' > certificate: type=FILE,location='/etc/pki/tls/certs/server.cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > Hi, thanks for your detailed report. Dogtag currently only supports $request.req_subject_name.{cn,uid}$. The error occurs because Dogtag does not populate the $request.req_subject_name.ou$ substitution variable thus the formatting of the subject name fails. If the OU is to be the same for all certificates, or if there are only a handful of values, you can make different profiles with constant OUs. If that is not adequate, we can file an RFE to add support for other DN components including OU. (Also, note that FreeIPA currently does not perform any validation of the OU in the CSR against the target principal's entry). Cheers, Fraser > Met vriendelijke groet, > > Wouter Hummelink > Cloud Engineer > [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] > KPN IT Solutions > Platform Organisation Cloud Services > Mail: wouter.hummelink at kpn.com > Telefoon: +31 (0)6 1288 2447 > [cid:image002.png at 01D0DA65.706AE4B0] > P Save Paper - Do you really need to print this e-mail? > ********************************************************************************************************************************************************* > KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam > The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. > Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons > and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately > and delete the material. Thank you. > ********************************************************************************************************************************************************* > > -- > 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 From morgan at marodin.it Fri Nov 27 15:31:49 2015 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 27 Nov 2015 16:31:49 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server Message-ID: Hi everyone. After updating my FreeIPA server to 7.2 OS version (it's a RHEL like distribution) I've some problems authenticating with Active Directory credentials. Testing it on 6.7 OS clients it works using Windows password, but using ticket kerberos it doesn't work. Testing it on 7.2 client it doesn't work either with password and kerberos tickets. What could be the problem? Please let me know, thanks. Bye, Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Nov 27 15:44:01 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Nov 2015 16:44:01 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: References: Message-ID: <20151127154401.GR4085@p.redhat.com> On Fri, Nov 27, 2015 at 04:31:49PM +0100, Morgan Marodin wrote: > Hi everyone. > > After updating my FreeIPA server to 7.2 OS version (it's a RHEL like > distribution) I've some problems authenticating with Active Directory > credentials. > > Testing it on 6.7 OS clients it works using Windows password, but using > ticket kerberos it doesn't work. > > Testing it on 7.2 client it doesn't work either with password and kerberos > tickets. Let's first start with password authentication. For this we need SSSD logs. Please see https://fedorahosted.org/sssd/wiki/Troubleshooting how to change the debug levels. The pam and domains logs would be useful. If you prefer you can send the logs to me directly. bye, Sumit > > What could be the problem? > > Please let me know, thanks. > Bye, Morgan > -- > 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 From morgan at marodin.it Fri Nov 27 16:35:42 2015 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 27 Nov 2015 17:35:42 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: <20151127154401.GR4085@p.redhat.com> References: <20151127154401.GR4085@p.redhat.com> Message-ID: Hi Sumit. I don't know why, but now kerberos ticket authentication is working on 6.7 clients. On 7.2 clients now password authetications with Active Directory credentials is working ... but not with kerberos ticket. There are my 7.2 client SSSD logs: --------------------------------------------------- ==> /var/log/sssd/sssd_nss.log <== (Fri Nov 27 17:12:51 2015) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[2383]. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f56192197a0][21] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Fri Nov 27 17:12:51 2015) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f56192197a0][21] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f56192197a0][21] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f56192197a0][21] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [morgan.marodin at mydomain.com]. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'morgan.marodin at mydomain.com' matched expression for domain ' mydomain.com', user is morgan.marodin (Fri Nov 27 17:12:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [morgan.marodin] from [mydomain.com] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/mydomain.com/morgan.marodin] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [morgan.marodin at mydomain.com] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f5619210d40 (Fri Nov 27 17:12:51 2015) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f5619217200 (Fri Nov 27 17:12:51 2015) [sssd[nss]] [ldb] (0x4000): Running timer event 0x7f5619210d40 "ltdb_callback" (Fri Nov 27 17:12:51 2015) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x7f5619217200 "ltdb_timeout" (Fri Nov 27 17:12:51 2015) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x7f5619210d40 "ltdb_callback" (Fri Nov 27 17:12:51 2015) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [check_cache] (0x0400): Cached entry is valid, returning.. (Fri Nov 27 17:12:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [morgan.marodin at mydomain.com] (Fri Nov 27 17:12:51 2015) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f56192197a0][21] ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging ipa.mydomain.com (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed51b10 (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed3c400 ==> /var/log/sssd/sssd_ipa.mydomain.com.log <== (Fri Nov 27 17:12:52 2015) [sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc5b4628010 (Fri Nov 27 17:12:52 2015) [sssd[be[ipa.mydomain.com]]] [sbus_dispatch] (0x4000): Dispatching. ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging sudo ==> /var/log/sssd/sssd_ipa.mydomain.com.log <== (Fri Nov 27 17:12:52 2015) [sssd[be[ipa.mydomain.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 27 17:12:52 2015) [sssd[be[ipa.mydomain.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd_nss.log <== (Fri Nov 27 17:12:52 2015) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x7f5619211cf0 (Fri Nov 27 17:12:52 2015) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd[nss]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed51d40 (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed467b0 (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh ==> /var/log/sssd/sssd_ipa.mydomain.com.log <== ==> /var/log/sssd/sssd_nss.log <== (Fri Nov 27 17:12:52 2015) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed3fd40 (Fri Nov 27 17:12:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pac ==> /var/log/sssd/sssd_nss.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_add_timeout] (0x2000): 0x7fad1ed50420 ==> /var/log/sssd/sssd_nss.log <== ==> /var/log/sssd/sssd.log <== ==> /var/log/sssd/sssd_sudo.log <== (Fri Nov 27 17:12:52 2015) [sssd[sudo]] [sbus_dispatch] (0x4000): dbus conn: 0x7f7cafe397a0 (Fri Nov 27 17:12:52 2015) [sssd[sudo]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd[sudo]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed51b10 ==> /var/log/sssd/sssd_sudo.log <== (Fri Nov 27 17:12:52 2015) [sssd[sudo]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd_pam.log <== (Fri Nov 27 17:12:52 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc5eaa6c7a0 (Fri Nov 27 17:12:52 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 27 17:12:52 2015) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed36500 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service ipa.mydomain.com replied to ping ==> /var/log/sssd/sssd_pam.log <== ==> /var/log/sssd/sssd_sudo.log <== ==> /var/log/sssd/sssd_pam.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed3c400 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed45270 ==> /var/log/sssd/sssd_ssh.log <== (Fri Nov 27 17:12:52 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn: 0x7f28ec7b97a0 (Fri Nov 27 17:12:52 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd[ssh]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 27 17:12:52 2015) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd_sudo.log <== ==> /var/log/sssd/sssd_pam.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping ==> /var/log/sssd/sssd_ssh.log <== ==> /var/log/sssd/sssd.log <== ==> /var/log/sssd/sssd_pac.log <== (Fri Nov 27 17:12:52 2015) [sssd[pac]] [sbus_dispatch] (0x4000): dbus conn: 0x7f3abbf7f7a0 (Fri Nov 27 17:12:52 2015) [sssd[pac]] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd[pac]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Nov 27 17:12:52 2015) [sssd[pac]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit ==> /var/log/sssd/sssd_ssh.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed467b0 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed3ce20 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. ==> /var/log/sssd/sssd_pac.log <== ==> /var/log/sssd/sssd_ssh.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping ==> /var/log/sssd/sssd_pac.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed51d40 ==> /var/log/sssd/sssd_pac.log <== ==> /var/log/sssd/sssd.log <== (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed3b3b0 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service sudo replied to ping (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed3fd40 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed407a0 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Fri Nov 27 17:12:52 2015) [sssd] [sbus_remove_timeout] (0x2000): 0x7fad1ed50420 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x7fad1ed4afb0 (Fri Nov 27 17:12:52 2015) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Nov 27 17:12:52 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping --------------------------------------------------- Anything else to enable debug mode? Please let le know, thanks. Bye, Morgan 2015-11-27 16:44 GMT+01:00 Sumit Bose : > On Fri, Nov 27, 2015 at 04:31:49PM +0100, Morgan Marodin wrote: > > Hi everyone. > > > > After updating my FreeIPA server to 7.2 OS version (it's a RHEL like > > distribution) I've some problems authenticating with Active Directory > > credentials. > > > > Testing it on 6.7 OS clients it works using Windows password, but using > > ticket kerberos it doesn't work. > > > > Testing it on 7.2 client it doesn't work either with password and > kerberos > > tickets. > > Let's first start with password authentication. For this we need SSSD > logs. Please see https://fedorahosted.org/sssd/wiki/Troubleshooting how > to change the debug levels. The pam and domains logs would be useful. If > you prefer you can send the logs to me directly. > > bye, > Sumit > > > > > What could be the problem? > > > > Please let me know, thanks. > > Bye, Morgan > > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Nov 27 16:47:47 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Nov 2015 17:47:47 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: References: <20151127154401.GR4085@p.redhat.com> Message-ID: <20151127164747.GS4085@p.redhat.com> On Fri, Nov 27, 2015 at 05:35:42PM +0100, Morgan Marodin wrote: > Hi Sumit. > > I don't know why, but now kerberos ticket authentication is working on 6.7 > clients. > On 7.2 clients now password authetications with Active Directory > credentials is working ... but not with kerberos ticket. This is most likely due to some issues while mapping the Kerberos principal to the local user name. Do you have a 'includedir /var/lib/sss/pubconf/krb5.include.d/' line at the beginning of you krb5.conf file? Does /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists? bye, Sumit From morgan at marodin.it Fri Nov 27 17:16:51 2015 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 27 Nov 2015 18:16:51 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: <20151127164747.GS4085@p.redhat.com> References: <20151127154401.GR4085@p.redhat.com> <20151127164747.GS4085@p.redhat.com> Message-ID: Yes: ------ # ls -l /var/lib/sss/pubconf/krb5.include.d/ total 8 -rw-r--r-- 1 root root 208 Nov 27 17:37 domain_realm_ipa_mydomain_com -rw-r--r-- 1 root root 118 Nov 27 17:37 localauth_plugin So what could I try to do? Thanks, Morgan 2015-11-27 17:47 GMT+01:00 Sumit Bose : > On Fri, Nov 27, 2015 at 05:35:42PM +0100, Morgan Marodin wrote: > > Hi Sumit. > > > > I don't know why, but now kerberos ticket authentication is working on > 6.7 > > clients. > > On 7.2 clients now password authetications with Active Directory > > credentials is working ... but not with kerberos ticket. > > This is most likely due to some issues while mapping the Kerberos > principal to the local user name. > > Do you have a 'includedir /var/lib/sss/pubconf/krb5.include.d/' line at > the beginning of you krb5.conf file? Does > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists? > > bye, > Sumit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Nov 27 17:38:03 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Nov 2015 18:38:03 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: References: <20151127154401.GR4085@p.redhat.com> <20151127164747.GS4085@p.redhat.com> Message-ID: <20151127173803.GT4085@p.redhat.com> On Fri, Nov 27, 2015 at 06:16:51PM +0100, Morgan Marodin wrote: > Yes: > ------ > # ls -l /var/lib/sss/pubconf/krb5.include.d/ > total 8 > -rw-r--r-- 1 root root 208 Nov 27 17:37 domain_realm_ipa_mydomain_com > -rw-r--r-- 1 root root 118 Nov 27 17:37 localauth_plugin > > So what could I try to do? 'getent passwd' should return the same entry for the user name you use at the login prompt and the Kerberos principal (its the name shown by klist in the 'Default principal:' line) e.g.: # getent passwd tu1 at ad.devel tu1 at ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh # getent passwd tu1 at AD.DEVEL tu1 at ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh >From the logs I guess you used the name 'morgan.marodin at mydomain.com' at the login prompt. I assume you use ssh for the Kerberos/GSSAPI login. Please check on the client with klist if you got a service ticket for your linux client principal which should look like host/linux.client.name at IPA.DOMAIN. On Windows there is klist for the cmd shell as well. Additionally if there is a service ticket for the linux host sshd debug logs from the linux host would be useful. For this please set LogLevel to DEBUG3 in /etc/ssh/sshd_config (please note that the log might contain confidential keys or passwords). bye, Sumit > Thanks, Morgan > > 2015-11-27 17:47 GMT+01:00 Sumit Bose : > > > On Fri, Nov 27, 2015 at 05:35:42PM +0100, Morgan Marodin wrote: > > > Hi Sumit. > > > > > > I don't know why, but now kerberos ticket authentication is working on > > 6.7 > > > clients. > > > On 7.2 clients now password authetications with Active Directory > > > credentials is working ... but not with kerberos ticket. > > > > This is most likely due to some issues while mapping the Kerberos > > principal to the local user name. > > > > Do you have a 'includedir /var/lib/sss/pubconf/krb5.include.d/' line at > > the beginning of you krb5.conf file? Does > > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists? > > > > bye, > > Sumit > > From guldberg72 at gmail.com Fri Nov 27 22:04:28 2015 From: guldberg72 at gmail.com (Daniel Guldberg aaes) Date: Fri, 27 Nov 2015 23:04:28 +0100 Subject: [Freeipa-users] (no subject) Message-ID: Hello. I am trying to setup FreeIPA but i am getting the following error when i do a ipa-server-install, I am trying to set it up on a ESXI 6 VM (The vm is a fresh install of Centos) ###############Installation precedure################################### wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm rpm -ivh epel-release-7-5.noarch.rpm yum install -y haveged yum install -y ipa-server bind bind-dyndb-ldap ##################Version#################################### 4.1.0, API_VERSION: 2.112 on a CentOs 7. Linux version 3.10.0-229.20.1.el7.x86_64 (builder at kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue Nov 3 19:10:07 UTC 2015 #############Error ############################################ [2/27]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpYbSmkT'' returned non-zero exit status 1 [error] RuntimeError: Configuration of CA failed Configuration of CA failed I can't figure out where the error is or what to correct ? The full .log is here : https://owncloud.techknight.eu/index.php/s/wH8TATlPvJODIeo -- *M.v.h Daniel Guldberg Aaes* -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at stefany.eu Fri Nov 27 22:59:45 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Fri, 27 Nov 2015 23:59:45 +0100 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <1448665185.5479.20.camel@stefany.eu> Hello, I remember experiencing this, but I'm not sure of solution. I think it's related to apache (httpd) and his group. My notes for IPA installation on CentOS 7.x say: # groupadd -g 48 apache # yum -y install ipa-server bind bind-dyndb-ldap # usermod -g apache apache #?ipa-server-install... CentOS is somehow not creating group apache for apache user and then assuming root which is then causing problems with apache later. Pre- creating such group before installing httpd and then usermod-ing user apache might solve it. Did you get any warnings while running: # yum install -y ipa-server bind bind-dyndb-ldap ? If possible, try installation from scratch with my notes on fresh system. If not: # systemctl stop apache ? # if it runs # groupadd -g 48 apache ? # I use 48 as apache's UID tends to be also 48, or use 'groupadd -r apache' instead # usermod -g apache apache # ipa-server-install... M. On Pi, 2015-11-27 at 23:04 +0100, Daniel Guldberg aaes wrote: > Hello. I am trying to setup FreeIPA but i am getting the following > error when i do a ipa-server-install, I am trying to set it up on a > ESXI 6 VM (The vm is a fresh install of Centos) > > ###############Installation > precedure################################### > wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5. > noarch.rpm > rpm -ivh epel-release-7-5.noarch.rpm > yum install -y haveged > yum install -y ipa-server bind bind-dyndb-ldap > ##################Version#################################### > 4.1.0, API_VERSION: 2.112 on a CentOs 7. > Linux version 3.10.0-229.20.1.el7.x86_64 (builder at kbuilder.dev.centos. > org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue > Nov 3 19:10:07 UTC 2015 > #############Error ############################################ > [2/27]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpYbSmkT'' returned non- > zero exit status 1 > ? [error] RuntimeError: Configuration of CA failed > Configuration of CA failed > I can't figure out where the error is or what to correct ? The full > .log is here : https://owncloud.techknight.eu/index.php/s/wH8TATlPvJOD > Ieo > > > -- > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Fri Nov 27 23:14:39 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Nov 2015 18:14:39 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: <1448665185.5479.20.camel@stefany.eu> References: <1448665185.5479.20.camel@stefany.eu> Message-ID: <5658E3DF.2020503@redhat.com> Martin ?tefany wrote: > Hello, > > I remember experiencing this, but I'm not sure of solution. I think it's > related to apache (httpd) and his group. > > My notes for IPA installation on CentOS 7.x say: > > # groupadd -g 48 apache > # yum -y install ipa-server bind bind-dyndb-ldap > # usermod -g apache apache > # ipa-server-install... > > CentOS is somehow not creating group apache for apache user and then > assuming root which is then causing problems with apache later. Pre- > creating such group before installing httpd and then usermod-ing user > apache might solve it. > > Did you get any warnings while running: > # yum install -y ipa-server bind bind-dyndb-ldap ? > > > If possible, try installation from scratch with my notes on fresh > system. If not: > > # systemctl stop apache # if it runs > # groupadd -g 48 apache # I use 48 as apache's UID tends to be also > 48, or use 'groupadd -r apache' instead > # usermod -g apache apache > # ipa-server-install... > Sounds unlikely to me. If indeed it did happen you'd need to file a bug against Apache to create its own uid/gid, which I'm pretty certain it already does. In any case, dogtag doesn't run in Apache so it would be unlikely to blow up in the CA installer. cating the contents of a directory into one log is not at all helpful, especially given that you missed all the important bits in the subdirectories beneath it. This is just a mishmash of stuff. We need to see /var/log/pki/pki-tomcat/ca/debug. /var/log/ipaserver-install.log might also be useful to see though it probably just records in a more verbose way the fact that pkispawn failed. rob From tobeychris at hotmail.com Mon Nov 30 03:17:22 2015 From: tobeychris at hotmail.com (Chris Tobey) Date: Mon, 30 Nov 2015 03:17:22 +0000 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA In-Reply-To: <007001d10a71$7c021af0$740650d0$@gmail.com> References: <0a3801d10480$2d152320$873f6960$@gmail.com> <007001d10a71$7c021af0$740650d0$@gmail.com> Message-ID: Any chance anyone knows more about this? I do see the following created for the admin user: ipaNTSecurityIdentifier: S-1-5-**-******* but ipa-adtrust-install seems to fail and not install the attribute for any of the other ~50 users. That may not help me with the sambaSID issue, but I would like to get the build-in tools working. Thanks, -Chris From: Youenn PIOLET [mailto:piolet.y at gmail.com] Sent: October-19-15 8:34 AM To: Chris Tobey Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Hi Chris, This may come from the ipa attributes added by adtrust on user/group classes. For example in 4.1.4: FreeIPA will add on each user the attribute (for ipasam.so usage): ipaNTSecurityIdentifier: S-1-5-**-******* when standard samba attributes known by samba with ldapsam.so are: sambaSID: S-1-5-**-******* I guess as the OID must be different, your CIFS will not recognise the attribute and won't be able to use it. I also guess it is the same for the password hash that may not be using the right algorithm. You can check this directly in your IPA 365directory tree, and with dirsrv logfiles. I suppose you would see FreeNAS trying to search for specific attributes in user objects that don't exist. These informations are based on deduction but I'm not confident enough to assure you this is a fact :) -- Youenn Piolet piolet.y at gmail.com 2015-10-17 16:47 GMT+02:00 Chris Tobey >: Hi Youenn, Thank you for the response. I am sure the issue is related to the samba attributes not existing, but I am not fully clear on how to fix it. I was trying to find out the correct steps on a CentOS system, and I think it is something like: >yum remove samba-common >yum install samba4 >yum install ipa-server-trust-ad >ipa-adtrust-install I thought the ipa-adtrust-install was supposed to add the samba attributes, but for some reason it still does not work. Does anyone have any insight in what steps I might have missed? Thanks, -Chris From: Youenn PIOLET [mailto:piolet.y at gmail.com] Sent: October-11-15 6:49 PM To: Chris Tobey Cc: freeipa-users at redhat.com; Matt . Subject: Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Sorry for the double post. I forgot to say that my speech is about newest versions of FreeIPA. Maybe someone here knows something about IPA 3.0 ? I'm not sure it used to work with ipasam module. But I suppose the problem is the same: you need to generate Samba schema values for your IPA users in the directory. Cheers, -- Youenn Piolet piolet.y at gmail.com 2015-10-12 0:41 GMT+02:00 Youenn PIOLET >: Hi Chris, First, to be sure were on the same page: Without IPA, to make CIFS users authenticate against directory in a classic LDAP implementation, you need to extend your LDAP tree with Samba schema. The FreeNAS documentation is a bit light on this subjet and previous FreeNAS versions (stable 9.3 included) used to mess up rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your 9.2 version. Wrote some messy stuff about it here: https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md To make CIFS users authenticate or FreeIPA recent versions (I only tried with 4.1), I suggest you to start by reading some of our investigations in this thread: [Freeipa-users] Ubuntu Samba Server Auth against IPA https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 When we discuss about this in august, I've spend almost a week trying to make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without fully understand why it didn't work, and moved our CIFS to a dedicated Centos server. Matt arrived with a similar situation in Ubuntu. To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default with ldapsam.so module. FreeIPA developpers have built a AD trust exchange possibility with a custom ipasam module that isn't compiled yet for Ubuntu or FreeNAS. This module gives the possibility to use IPA AD trust components (e.g. special schema in IPA's directory managing user/group NT SID) If you can't compile the module for FreeNAS / FreeBSD, you may need to extend 365directory with Samba schema. You will need to find a way to generate the new attributes when adding users or groups in FreeIPA, and a way to store password in a CIFS/NT understandable way. I don't suggest you to follow this dark path. You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) Good luck in your experimentations, I hope you will succeed! -- Youenn Piolet piolet.y at gmail.com 2015-10-11 2:06 GMT+02:00 Chris Tobey >: Hi Everyone, I have a functioning FreeIPA server that manages all my users and I would like to also use it for my FreeNAS CIFS shares to authenticate against. Does anyone know what needs to be run on both servers to get this working? I believe it has something to do with Samba properties on the FreeIPA side. I had tried asking the FreeNAS forums but they were of no help (https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/). I have seen similar requests and success stories, but no actual steps on how to do it. Info: FreeIPA v3.0.0-42 running on CentOS 6.6. FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working before dealing with certs). Any help is appreciated. Thanks, -Chris -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlau at tetrioncapital.com Mon Nov 30 03:26:06 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Mon, 30 Nov 2015 11:26:06 +0800 Subject: [Freeipa-users] Ticket transfer from host to host Message-ID: ?Hi all, I am running FreeIPA 3.3.x in our environment. First I did is kinit on client 1, then ssh to host A, it works fine; But then if I want to ssh from host A to host B, I have to do kinit again, is there have a way to do ticket transfer? Or is it call "Ticket Delegation"? How could I config it to function properly?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 30 03:39:44 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 29 Nov 2015 22:39:44 -0500 Subject: [Freeipa-users] Ticket transfer from host to host In-Reply-To: References: Message-ID: <565BC500.3060906@redhat.com> Thomas Lau wrote: > ?Hi all, > > I am running FreeIPA 3.3.x in our environment. First I did is kinit on > client 1, then ssh to host A, it works fine; But then if I want to ssh > from host A to host B, I have to do kinit again, is there have a way to > do ticket transfer? Or is it call "Ticket Delegation"? How could I > config it to function properly?? > > man ssh -K Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server. rob From tlau at tetrioncapital.com Mon Nov 30 06:32:51 2015 From: tlau at tetrioncapital.com (Thomas Lau) Date: Mon, 30 Nov 2015 14:32:51 +0800 Subject: [Freeipa-users] Ticket transfer from host to host In-Reply-To: <565BC500.3060906@redhat.com> References: <565BC500.3060906@redhat.com> Message-ID: Hi Rob, So what you are trying to say is that it's nothing to do with FreeIPA but ssh client itself? On Mon, Nov 30, 2015 at 11:39 AM, Rob Crittenden wrote: > Thomas Lau wrote: > > ?Hi all, > > > > I am running FreeIPA 3.3.x in our environment. First I did is kinit on > > client 1, then ssh to host A, it works fine; But then if I want to ssh > > from host A to host B, I have to do kinit again, is there have a way to > > do ticket transfer? Or is it call "Ticket Delegation"? How could I > > config it to function properly?? > > > > > > man ssh > > -K Enables GSSAPI-based authentication and forwarding > (delegation) > of GSSAPI credentials to the server. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan at marodin.it Mon Nov 30 09:00:13 2015 From: morgan at marodin.it (Morgan Marodin) Date: Mon, 30 Nov 2015 10:00:13 +0100 Subject: [Freeipa-users] Problem with AD authentication after updating to 7.2 OS server In-Reply-To: <20151127173803.GT4085@p.redhat.com> References: <20151127154401.GR4085@p.redhat.com> <20151127164747.GS4085@p.redhat.com> <20151127173803.GT4085@p.redhat.com> Message-ID: I've found the problem, using DEBUG3 into SSH service: --------------------------------------------------------------------------------- Nov 30 08:52:47 myserver sshd[9639]: debug1: Unspecified GSS failure. Minor code may provide more information\nClock skew too great\n Nov 30 08:52:47 myserver sshd[9639]: debug1: Got no client credentials Nov 30 08:52:47 myserver sshd[9639]: debug3: mm_request_send entering: type 45 Nov 30 08:52:47 myserver sshd[9639]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth] Nov 30 08:52:47 myserver sshd[9639]: debug1: Received SSH2_MSG_UNIMPLEMENTED for 7 [preauth] My client was 4 minutes early than IPA server. After syncing time via ntpdate kerberos ticket authentication works correctly. Thanks for your support, bye. Morgan 2015-11-27 18:38 GMT+01:00 Sumit Bose : > On Fri, Nov 27, 2015 at 06:16:51PM +0100, Morgan Marodin wrote: > > Yes: > > ------ > > # ls -l /var/lib/sss/pubconf/krb5.include.d/ > > total 8 > > -rw-r--r-- 1 root root 208 Nov 27 17:37 domain_realm_ipa_mydomain_com > > -rw-r--r-- 1 root root 118 Nov 27 17:37 localauth_plugin > > > > So what could I try to do? > > 'getent passwd' should return the same entry for the user name you use > at the login prompt and the Kerberos principal (its the name shown by > klist in the 'Default principal:' line) e.g.: > > # getent passwd tu1 at ad.devel > tu1 at ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh > # getent passwd tu1 at AD.DEVEL > tu1 at ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh > > From the logs I guess you used the name 'morgan.marodin at mydomain.com' at > the login prompt. > > I assume you use ssh for the Kerberos/GSSAPI login. Please check on the > client with klist if you got a service ticket for your linux client > principal which should look like host/linux.client.name at IPA.DOMAIN. On > Windows there is klist for the cmd shell as well. > > Additionally if there is a service ticket for the linux host sshd debug > logs from the linux host would be useful. For this please set LogLevel to > DEBUG3 in /etc/ssh/sshd_config (please note that the log might contain > confidential keys or passwords). > > bye, > Sumit > > > Thanks, Morgan > > > > 2015-11-27 17:47 GMT+01:00 Sumit Bose : > > > > > On Fri, Nov 27, 2015 at 05:35:42PM +0100, Morgan Marodin wrote: > > > > Hi Sumit. > > > > > > > > I don't know why, but now kerberos ticket authentication is working > on > > > 6.7 > > > > clients. > > > > On 7.2 clients now password authetications with Active Directory > > > > credentials is working ... but not with kerberos ticket. > > > > > > This is most likely due to some issues while mapping the Kerberos > > > principal to the local user name. > > > > > > Do you have a 'includedir /var/lib/sss/pubconf/krb5.include.d/' line at > > > the beginning of you krb5.conf file? Does > > > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists? > > > > > > bye, > > > Sumit > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.calminder at nordnet.se Mon Nov 30 09:12:14 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Mon, 30 Nov 2015 10:12:14 +0100 Subject: [Freeipa-users] FreeIPA 4.1 -> 4.2 replica upgrade process Message-ID: <565C12EE.7070606@nordnet.se> Hello! This might be trivial but I want to double check the preferred way of upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 4.1), 1 acting as master with a ca (external certificate), the replicas are also ca's, they're only syncing to and from the master, unaware of each other. The replicas handle all client requests. The master also run a one-way winsync agreement with one of our active directory servers. For some reason I think that I should start by upgrading the replicas and upgrade the master last, but I don't know why, I might have read it in somewhere, long ago. Is this the preferred way, does order even matter? The documentation just says /yum update ipa-server/ which seems easy enough, but I'd rather double check. Best regards, Andreas From alexanders.mailinglists+nospam at gmail.com Mon Nov 30 09:25:39 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Mon, 30 Nov 2015 10:25:39 +0100 Subject: [Freeipa-users] HBAC - Limit SSH access to "test" systems Message-ID: Hello I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04 FreeIPA 3.3.4 clients so, that users in a user group called "customers" can only access hosts, which are in a host group called "test". Users from the user group "ops" should be able to access all systems (ie. "prod" systems and also those "test" systems). But I cannot get my head around to create proper HBAC rules/setup? Could somebody maybe lend me a helping hand? At the moment, I have set it up so, that I modified the "prod" systems sshd_config and added "DenyGroups customer" there. On the test systems, I don't have that line. That works, but it's not using IPA (in a sense? I do have to modify the hosts configuration on the system, which I dislike. Granted, with Chef, it's not much, but still *G*). Thanks, Alexander -- => Google+ => http://plus.skwar.me <== => Chat (Jabber/Google Talk) => a.skwar at gmail.com <== From abokovoy at redhat.com Mon Nov 30 09:38:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Nov 2015 11:38:52 +0200 Subject: [Freeipa-users] HBAC - Limit SSH access to "test" systems In-Reply-To: References: Message-ID: <20151130093852.GA9605@redhat.com> On Mon, 30 Nov 2015, Alexander Skwar wrote: >Hello > >I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04 >FreeIPA 3.3.4 clients so, that users in a user group called "customers" >can only access hosts, which are in a host group called "test". Users >from the user group "ops" should be able to access all systems (ie. >"prod" systems and also those "test" systems). > >But I cannot get my head around to create proper HBAC rules/setup? > >Could somebody maybe lend me a helping hand? > >At the moment, I have set it up so, that I modified the "prod" systems >sshd_config and added "DenyGroups customer" there. On the test systems, >I don't have that line. That works, but it's not using IPA (in a sense? >I do have to modify the hosts configuration on the system, which I >dislike. Granted, with Chef, it's not much, but still *G*). HBAC is enforced by SSSD over PAM. All you need to ensure is that an application (sshd in this case) uses PAM. Then you setup HBAC rules, disable allow_all rule, and then SSSD will verify rules on logon via sshd, checking all rules for service 'sshd' and applying to this host (via hostgroup or to all hosts). -- / Alexander Bokovoy From alexanders.mailinglists+nospam at gmail.com Mon Nov 30 10:18:15 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Mon, 30 Nov 2015 11:18:15 +0100 Subject: [Freeipa-users] HBAC - Limit SSH access to "test" systems In-Reply-To: <20151130093852.GA9605@redhat.com> References: <20151130093852.GA9605@redhat.com> Message-ID: Hello Alexander ;) 2015-11-30 10:38 GMT+01:00 Alexander Bokovoy : > HBAC is enforced by SSSD over PAM. All you need to ensure is that an > application (sshd in this case) uses PAM. Then you setup HBAC rules, > disable allow_all rule, and then SSSD will verify rules on logon via > sshd, checking all rules for service 'sshd' and applying to this host > (via hostgroup or to all hosts). Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also change the "default" behaviour? I mean, by default, everything will be allowed for everyone on every system. When I deactivate the allow_all - won't that mean, that nothing will be allowed for everyone on all systems? Playing with the HBAC Test thingie in the web interface seems to imply that. And because of that, I now have 3 rules: 1) allow_all_but_ssh 2) ssh_prod 3) ssh_test 1) Who: Anyone, Accessing: Any host, Via Service: Selected every service, but not sshd 2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd 3) Who: Anyone, Accessing: Host groups: test, Via service: sshd That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there. Reason: I manually have to select every service and remove sshd. But if a new service were to be added, I'd have to remember to add it there as well. Not cool. Even more so, because I'm not the only admin. Colleagues would have to know this as well. Not cool?. Somehow I'm missing "deny"-rules, I think. Nice to have allow rules, but I'm rather looking for a way to deny something :/ Don't know, but that seems to be too complicated. Or is that really the way to do that? Thanks a lot, Alexander -- => Google+ => http://plus.skwar.me <== => Chat (Jabber/Google Talk) => a.skwar at gmail.com <== From jpazdziora at redhat.com Mon Nov 30 10:52:57 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 30 Nov 2015 11:52:57 +0100 Subject: [Freeipa-users] HBAC - Limit SSH access to "test" systems In-Reply-To: References: <20151130093852.GA9605@redhat.com> Message-ID: <20151130105257.GN12899@redhat.com> On Mon, Nov 30, 2015 at 11:18:15AM +0100, Alexander Skwar wrote: > > Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also > change the "default" behaviour? I mean, by default, everything will > be allowed for everyone on every system. No. > When I deactivate the allow_all - won't that mean, that nothing will > be allowed for everyone on all systems? That's right, nothing will be allowed. Disabling allow_all has the potential of making everything stop working. You need to plan carefully and replace the allow_all with tailored rules. For example, see http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Mon Nov 30 10:58:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Nov 2015 12:58:06 +0200 Subject: [Freeipa-users] HBAC - Limit SSH access to "test" systems In-Reply-To: References: <20151130093852.GA9605@redhat.com> Message-ID: <20151130105806.GB9605@redhat.com> On Mon, 30 Nov 2015, Alexander Skwar wrote: >Hello Alexander ;) > >2015-11-30 10:38 GMT+01:00 Alexander Bokovoy : > >> HBAC is enforced by SSSD over PAM. All you need to ensure is that an >> application (sshd in this case) uses PAM. Then you setup HBAC rules, >> disable allow_all rule, and then SSSD will verify rules on logon via >> sshd, checking all rules for service 'sshd' and applying to this host >> (via hostgroup or to all hosts). > >Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also >change the "default" behaviour? I mean, by default, everything will >be allowed for everyone on every system. > >When I deactivate the allow_all - won't that mean, that nothing will >be allowed for everyone on all systems? Yes. HBAC system is built around a simple principle: everything is denied unless allowed explicitly with specific rules. We supply 'allow_all' rule for defaults and it is your duty to create HBAC rules which suit your deployment needs. >Playing with the HBAC Test thingie in the web interface seems to imply >that. And because of that, I now have 3 rules: > >1) allow_all_but_ssh >2) ssh_prod >3) ssh_test > >1) Who: Anyone, Accessing: Any host, Via Service: Selected every > service, but not sshd >2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd >3) Who: Anyone, Accessing: Host groups: test, Via service: sshd > >That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there. >Reason: I manually have to select every service and remove sshd. But if >a new service were to be added, I'd have to remember to add it there as >well. Not cool. Even more so, because I'm not the only admin. Colleagues >would have to know this as well. Not cool?. > >Somehow I'm missing "deny"-rules, I think. Nice to have allow rules, >but I'm rather looking for a way to deny something :/ > >Don't know, but that seems to be too complicated. Or is that really the >way to do that? Deny rules complicate things a lot, really. You can create a service group that includes all your services but sshd and assign that service group to allow rule. Maintaining a service group is less problematic than looking into what rules deny/allow. Consider also the contextual problem of what to do if HBAC rules become unavailable -- should the unavailability of deny rule be treated as allow or not? We chose to define deny by default and add allow rules on top of it. All this is covered in IPA documentation. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html -- / Alexander Bokovoy From mbasti at redhat.com Mon Nov 30 10:58:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 11:58:15 +0100 Subject: [Freeipa-users] FreeIPA 4.1 -> 4.2 replica upgrade process In-Reply-To: <565C12EE.7070606@nordnet.se> References: <565C12EE.7070606@nordnet.se> Message-ID: <565C2BC7.2070306@redhat.com> On 30.11.2015 10:12, Andreas Calminder wrote: > Hello! > This might be trivial but I want to double check the preferred way of > upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa > 4.1), 1 acting as master with a ca (external certificate), the > replicas are also ca's, they're only syncing to and from the master, > unaware of each other. The replicas handle all client requests. The > master also run a one-way winsync agreement with one of our active > directory servers. > > For some reason I think that I should start by upgrading the replicas > and upgrade the master last, but I don't know why, I might have read > it in somewhere, long ago. Is this the preferred way, does order even > matter? The documentation just says /yum update ipa-server/ which > seems easy enough, but I'd rather double check. > > Best regards, > Andreas > Hello, replicas and master are equal, so it should not matter which is upgraded as first. Martin From mbasti at redhat.com Mon Nov 30 11:51:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 12:51:51 +0100 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <5658E3DF.2020503@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> Message-ID: <565C3857.7000002@redhat.com> On 28.11.2015 00:14, Rob Crittenden wrote: > Martin ?tefany wrote: >> Hello, >> >> I remember experiencing this, but I'm not sure of solution. I think it's >> related to apache (httpd) and his group. >> >> My notes for IPA installation on CentOS 7.x say: >> >> # groupadd -g 48 apache >> # yum -y install ipa-server bind bind-dyndb-ldap >> # usermod -g apache apache >> # ipa-server-install... >> >> CentOS is somehow not creating group apache for apache user and then >> assuming root which is then causing problems with apache later. Pre- >> creating such group before installing httpd and then usermod-ing user >> apache might solve it. >> >> Did you get any warnings while running: >> # yum install -y ipa-server bind bind-dyndb-ldap ? >> >> >> If possible, try installation from scratch with my notes on fresh >> system. If not: >> >> # systemctl stop apache # if it runs >> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >> 48, or use 'groupadd -r apache' instead >> # usermod -g apache apache >> # ipa-server-install... >> > Sounds unlikely to me. If indeed it did happen you'd need to file a bug > against Apache to create its own uid/gid, which I'm pretty certain it > already does. > > In any case, dogtag doesn't run in Apache so it would be unlikely to > blow up in the CA installer. > > cating the contents of a directory into one log is not at all helpful, > especially given that you missed all the important bits in the > subdirectories beneath it. This is just a mishmash of stuff. We need to > see /var/log/pki/pki-tomcat/ca/debug. > > /var/log/ipaserver-install.log might also be useful to see though it > probably just records in a more verbose way the fact that pkispawn failed. > > rob > Hello, I see in log this error message: 2015-11-26 08:41:53 pkidestroy : ERROR ....... subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', '/etc/pki/pki-tomcat/alias', '-e', 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned non-zero exit status 6! It means that the CA has no been sucessfully uninstalled, and it can cause issues during installation PKI bug: https://fedorahosted.org/pki/ticket/1704 Christian may have workaround (CCed) Martin From gjn at gjn.priv.at Mon Nov 30 12:27:04 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 30 Nov 2015 13:27:04 +0100 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question Message-ID: <2188056.Z0q5x72BSD@techz> Hello , I have the question, know any from the FreeIPA "Gurus" ;-), are the new upcoming LetsEncrypt Certificates compatible and working with FreeIPA? Thanks for a answer, -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From andreas.calminder at nordnet.se Mon Nov 30 12:32:56 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Mon, 30 Nov 2015 13:32:56 +0100 Subject: [Freeipa-users] FreeIPA 4.1 -> 4.2 replica upgrade process In-Reply-To: <565C2BC7.2070306@redhat.com> References: <565C12EE.7070606@nordnet.se> <565C2BC7.2070306@redhat.com> Message-ID: <565C41F8.7010907@nordnet.se> Great, thanks! I'll just go ahead and yum update then :). /andreas On 11/30/2015 11:58 AM, Martin Basti wrote: > > > On 30.11.2015 10:12, Andreas Calminder wrote: >> Hello! >> This might be trivial but I want to double check the preferred way of >> upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa >> 4.1), 1 acting as master with a ca (external certificate), the >> replicas are also ca's, they're only syncing to and from the master, >> unaware of each other. The replicas handle all client requests. The >> master also run a one-way winsync agreement with one of our active >> directory servers. >> >> For some reason I think that I should start by upgrading the replicas >> and upgrade the master last, but I don't know why, I might have read >> it in somewhere, long ago. Is this the preferred way, does order even >> matter? The documentation just says /yum update ipa-server/ which >> seems easy enough, but I'd rather double check. >> >> Best regards, >> Andreas >> > Hello, > > replicas and master are equal, so it should not matter which is > upgraded as first. > > Martin From abokovoy at redhat.com Mon Nov 30 12:46:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Nov 2015 14:46:13 +0200 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question In-Reply-To: <2188056.Z0q5x72BSD@techz> References: <2188056.Z0q5x72BSD@techz> Message-ID: <20151130124613.GD9605@redhat.com> On Mon, 30 Nov 2015, G?nther J. Niederwimmer wrote: >Hello , > >I have the question, know any from the FreeIPA "Gurus" ;-), are the new >upcoming LetsEncrypt Certificates compatible and working with FreeIPA? We have plans to support issuing certificates via Let's Encrypt. However, right now Let's encrypt only issues server certificates, not CA roots, so you cannot use them to bootstrap IPA CA. -- / Alexander Bokovoy From mkosek at redhat.com Mon Nov 30 12:49:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Nov 2015 13:49:13 +0100 Subject: [Freeipa-users] FreeIPA 4.1 -> 4.2 replica upgrade process In-Reply-To: <565C41F8.7010907@nordnet.se> References: <565C12EE.7070606@nordnet.se> <565C2BC7.2070306@redhat.com> <565C41F8.7010907@nordnet.se> Message-ID: <565C45C9.2080808@redhat.com> On 11/30/2015 01:32 PM, Andreas Calminder wrote: > Great, thanks! > I'll just go ahead and yum update then :). I would just recommend to upgrade one-by-one, to avoid replication conflicts if multiple masters add the same entries in the tree in the same time. > On 11/30/2015 11:58 AM, Martin Basti wrote: >> >> >> On 30.11.2015 10:12, Andreas Calminder wrote: >>> Hello! >>> This might be trivial but I want to double check the preferred way of >>> upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 4.1), >>> 1 acting as master with a ca (external certificate), the replicas are also >>> ca's, they're only syncing to and from the master, unaware of each other. >>> The replicas handle all client requests. The master also run a one-way >>> winsync agreement with one of our active directory servers. >>> >>> For some reason I think that I should start by upgrading the replicas and >>> upgrade the master last, but I don't know why, I might have read it in >>> somewhere, long ago. Is this the preferred way, does order even matter? The >>> documentation just says /yum update ipa-server/ which seems easy enough, but >>> I'd rather double check. >>> >>> Best regards, >>> Andreas >>> >> Hello, >> >> replicas and master are equal, so it should not matter which is upgraded as >> first. >> >> Martin > From cheimes at redhat.com Mon Nov 30 12:49:31 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 30 Nov 2015 13:49:31 +0100 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C3857.7000002@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> Message-ID: <565C45DB.1040605@redhat.com> On 2015-11-30 12:51, Martin Basti wrote: > > > On 28.11.2015 00:14, Rob Crittenden wrote: >> Martin ?tefany wrote: >>> Hello, >>> >>> I remember experiencing this, but I'm not sure of solution. I think it's >>> related to apache (httpd) and his group. >>> >>> My notes for IPA installation on CentOS 7.x say: >>> >>> # groupadd -g 48 apache >>> # yum -y install ipa-server bind bind-dyndb-ldap >>> # usermod -g apache apache >>> # ipa-server-install... >>> >>> CentOS is somehow not creating group apache for apache user and then >>> assuming root which is then causing problems with apache later. Pre- >>> creating such group before installing httpd and then usermod-ing user >>> apache might solve it. >>> >>> Did you get any warnings while running: >>> # yum install -y ipa-server bind bind-dyndb-ldap ? >>> >>> >>> If possible, try installation from scratch with my notes on fresh >>> system. If not: >>> >>> # systemctl stop apache # if it runs >>> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >>> 48, or use 'groupadd -r apache' instead >>> # usermod -g apache apache >>> # ipa-server-install... >>> >> Sounds unlikely to me. If indeed it did happen you'd need to file a bug >> against Apache to create its own uid/gid, which I'm pretty certain it >> already does. >> >> In any case, dogtag doesn't run in Apache so it would be unlikely to >> blow up in the CA installer. >> >> cating the contents of a directory into one log is not at all helpful, >> especially given that you missed all the important bits in the >> subdirectories beneath it. This is just a mishmash of stuff. We need to >> see /var/log/pki/pki-tomcat/ca/debug. >> >> /var/log/ipaserver-install.log might also be useful to see though it >> probably just records in a more verbose way the fact that pkispawn >> failed. >> >> rob >> > Hello, > > I see in log this error message: > > 2015-11-26 08:41:53 pkidestroy : ERROR ....... > subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', > 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', > '/etc/pki/pki-tomcat/alias', '-e', > 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', > '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned > non-zero exit status 6! > > It means that the CA has no been sucessfully uninstalled, and it can > cause issues during installation > PKI bug: > https://fedorahosted.org/pki/ticket/1704 > > Christian may have workaround (CCed) Hi Martin and Martin, last week I have identified an incompatibility between Dogtag's sslget command and Apache HTTP. sslget sends a server name indication during the TLS/SSL handshake but doesn't send a HTTP Host header. Newer versions of Apache HTTP don't accept requests with SNI and without HTTP Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log. The simplest workaround is to bypass Apache and talk to Dogtag directly. In order to do bypass the Apache proxy you have to log onto the server. You also have to become root so you can access the NSS database that contains the private key for authentication. Simply copy and paste the sslget command from the log (everything between "Command '[" and "]' returend non-zero exit status 6!"), remove the comma, replace 'ipa.home:443' with 'ipa.home:8443' and run the command. The command should look like: '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ... '/ca/agent/ca/updateDomainXML' 'ipa.home:8443' Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gasper.bregar at nets.si Mon Nov 30 13:25:27 2015 From: gasper.bregar at nets.si (=?UTF-8?Q?Ga=C5=A1per_Bregar?=) Date: Mon, 30 Nov 2015 14:25:27 +0100 Subject: [Freeipa-users] FreeIPA AD password sync Message-ID: I have been strugling with FreeIPA and AD password sync for a couple of days now. At first everything was working fine, but then all of a sudden the synchronization started to fail for me and another user. The error in passsync log was Ldap error in ModifyPassword > 50: Insufficient access It took me some time to figure out that it was failing just for the two us. It was failing because we were in the admin user group in FreeIPA. Is this intentional? Is it possible to somehow change this behaviour with a setting? Regards, Ga?per -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 30 15:27:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Nov 2015 10:27:26 -0500 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C45DB.1040605@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> Message-ID: <565C6ADE.4080108@redhat.com> Christian Heimes wrote: > On 2015-11-30 12:51, Martin Basti wrote: >> >> >> On 28.11.2015 00:14, Rob Crittenden wrote: >>> Martin ?tefany wrote: >>>> Hello, >>>> >>>> I remember experiencing this, but I'm not sure of solution. I think it's >>>> related to apache (httpd) and his group. >>>> >>>> My notes for IPA installation on CentOS 7.x say: >>>> >>>> # groupadd -g 48 apache >>>> # yum -y install ipa-server bind bind-dyndb-ldap >>>> # usermod -g apache apache >>>> # ipa-server-install... >>>> >>>> CentOS is somehow not creating group apache for apache user and then >>>> assuming root which is then causing problems with apache later. Pre- >>>> creating such group before installing httpd and then usermod-ing user >>>> apache might solve it. >>>> >>>> Did you get any warnings while running: >>>> # yum install -y ipa-server bind bind-dyndb-ldap ? >>>> >>>> >>>> If possible, try installation from scratch with my notes on fresh >>>> system. If not: >>>> >>>> # systemctl stop apache # if it runs >>>> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >>>> 48, or use 'groupadd -r apache' instead >>>> # usermod -g apache apache >>>> # ipa-server-install... >>>> >>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug >>> against Apache to create its own uid/gid, which I'm pretty certain it >>> already does. >>> >>> In any case, dogtag doesn't run in Apache so it would be unlikely to >>> blow up in the CA installer. >>> >>> cating the contents of a directory into one log is not at all helpful, >>> especially given that you missed all the important bits in the >>> subdirectories beneath it. This is just a mishmash of stuff. We need to >>> see /var/log/pki/pki-tomcat/ca/debug. >>> >>> /var/log/ipaserver-install.log might also be useful to see though it >>> probably just records in a more verbose way the fact that pkispawn >>> failed. >>> >>> rob >>> >> Hello, >> >> I see in log this error message: >> >> 2015-11-26 08:41:53 pkidestroy : ERROR ....... >> subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', >> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', >> '/etc/pki/pki-tomcat/alias', '-e', >> 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', >> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned >> non-zero exit status 6! >> >> It means that the CA has no been sucessfully uninstalled, and it can >> cause issues during installation >> PKI bug: >> https://fedorahosted.org/pki/ticket/1704 >> >> Christian may have workaround (CCed) > > Hi Martin and Martin, > > last week I have identified an incompatibility between Dogtag's sslget > command and Apache HTTP. sslget sends a server name indication during > the TLS/SSL handshake but doesn't send a HTTP Host header. Newer > versions of Apache HTTP don't accept requests with SNI and without HTTP > Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log. > > The simplest workaround is to bypass Apache and talk to Dogtag directly. > In order to do bypass the Apache proxy you have to log onto the server. > You also have to become root so you can access the NSS database that > contains the private key for authentication. Simply copy and paste the > sslget command from the log (everything between "Command '[" and "]' > returend non-zero exit status 6!"), remove the comma, replace > 'ipa.home:443' with 'ipa.home:8443' and run the command. The command > should look like: > > '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ... > '/ca/agent/ca/updateDomainXML' 'ipa.home:8443' mod_nss added support for SNI in Fedora 23. It should behave the same way as mod_ssl, denying a request that contains an SNI hostname but no Host header. I assume you've filed a bug against dogtag to send a Host header in the request? A better workaround would be to add NSSSNI off to /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install should work then, or at least get past this sslget error. rob From rcritten at redhat.com Mon Nov 30 15:28:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Nov 2015 10:28:58 -0500 Subject: [Freeipa-users] Ticket transfer from host to host In-Reply-To: References: <565BC500.3060906@redhat.com> Message-ID: <565C6B3A.3080000@redhat.com> Thomas Lau wrote: > Hi Rob, > > So what you are trying to say is that it's nothing to do with FreeIPA > but ssh client itself? Correct. rob > > On Mon, Nov 30, 2015 at 11:39 AM, Rob Crittenden > wrote: > > Thomas Lau wrote: > > ?Hi all, > > > > I am running FreeIPA 3.3.x in our environment. First I did is kinit on > > client 1, then ssh to host A, it works fine; But then if I want to ssh > > from host A to host B, I have to do kinit again, is there have a > way to > > do ticket transfer? Or is it call "Ticket Delegation"? How could I > > config it to function properly?? > > > > > > man ssh > > -K Enables GSSAPI-based authentication and forwarding > (delegation) > of GSSAPI credentials to the server. > > rob > > > > From cheimes at redhat.com Mon Nov 30 15:41:31 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 30 Nov 2015 16:41:31 +0100 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C6ADE.4080108@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> <565C6ADE.4080108@redhat.com> Message-ID: <565C6E2B.6090001@redhat.com> On 2015-11-30 16:27, Rob Crittenden wrote: > Christian Heimes wrote: >> On 2015-11-30 12:51, Martin Basti wrote: >>> >>> >>> On 28.11.2015 00:14, Rob Crittenden wrote: >>>> Martin ?tefany wrote: >>>>> Hello, >>>>> >>>>> I remember experiencing this, but I'm not sure of solution. I think it's >>>>> related to apache (httpd) and his group. >>>>> >>>>> My notes for IPA installation on CentOS 7.x say: >>>>> >>>>> # groupadd -g 48 apache >>>>> # yum -y install ipa-server bind bind-dyndb-ldap >>>>> # usermod -g apache apache >>>>> # ipa-server-install... >>>>> >>>>> CentOS is somehow not creating group apache for apache user and then >>>>> assuming root which is then causing problems with apache later. Pre- >>>>> creating such group before installing httpd and then usermod-ing user >>>>> apache might solve it. >>>>> >>>>> Did you get any warnings while running: >>>>> # yum install -y ipa-server bind bind-dyndb-ldap ? >>>>> >>>>> >>>>> If possible, try installation from scratch with my notes on fresh >>>>> system. If not: >>>>> >>>>> # systemctl stop apache # if it runs >>>>> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >>>>> 48, or use 'groupadd -r apache' instead >>>>> # usermod -g apache apache >>>>> # ipa-server-install... >>>>> >>>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug >>>> against Apache to create its own uid/gid, which I'm pretty certain it >>>> already does. >>>> >>>> In any case, dogtag doesn't run in Apache so it would be unlikely to >>>> blow up in the CA installer. >>>> >>>> cating the contents of a directory into one log is not at all helpful, >>>> especially given that you missed all the important bits in the >>>> subdirectories beneath it. This is just a mishmash of stuff. We need to >>>> see /var/log/pki/pki-tomcat/ca/debug. >>>> >>>> /var/log/ipaserver-install.log might also be useful to see though it >>>> probably just records in a more verbose way the fact that pkispawn >>>> failed. >>>> >>>> rob >>>> >>> Hello, >>> >>> I see in log this error message: >>> >>> 2015-11-26 08:41:53 pkidestroy : ERROR ....... >>> subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', >>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', >>> '/etc/pki/pki-tomcat/alias', '-e', >>> 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', >>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned >>> non-zero exit status 6! >>> >>> It means that the CA has no been sucessfully uninstalled, and it can >>> cause issues during installation >>> PKI bug: >>> https://fedorahosted.org/pki/ticket/1704 >>> >>> Christian may have workaround (CCed) >> >> Hi Martin and Martin, >> >> last week I have identified an incompatibility between Dogtag's sslget >> command and Apache HTTP. sslget sends a server name indication during >> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer >> versions of Apache HTTP don't accept requests with SNI and without HTTP >> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log. >> >> The simplest workaround is to bypass Apache and talk to Dogtag directly. >> In order to do bypass the Apache proxy you have to log onto the server. >> You also have to become root so you can access the NSS database that >> contains the private key for authentication. Simply copy and paste the >> sslget command from the log (everything between "Command '[" and "]' >> returend non-zero exit status 6!"), remove the comma, replace >> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command >> should look like: >> >> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ... >> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443' > > mod_nss added support for SNI in Fedora 23. It should behave the same > way as mod_ssl, denying a request that contains an SNI hostname but no > Host header. > > I assume you've filed a bug against dogtag to send a Host header in the > request? > > A better workaround would be to add NSSSNI off to > /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install > should work then, or at least get past this sslget error. That might explain why the issue hasn't popped up earlier. sslget sets SNI header without HTTP Host header for a while. Since FreeIPA uses mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header before, sslget didn't fail in the past. Yes, I have fixed sslget to send a HTTP Host header with hostname and port. No, that won't work. You'd have to change the configuration before you run uninstall. Install still won't work because uninstall was incomplete. It's still necessary to remove the Service Domain for the CA from LDAP. The sslget command call removes it. It's also possible to remove it with ldapremove over ldapi. The entry is in the cn=CAList,ou=Security Domain,o=ipaca subtree. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Mon Nov 30 16:45:47 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Nov 2015 11:45:47 -0500 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C6E2B.6090001@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> <565C6ADE.4080108@redhat.com> <565C6E2B.6090001@redhat.com> Message-ID: <565C7D3B.5070506@redhat.com> Christian Heimes wrote: > On 2015-11-30 16:27, Rob Crittenden wrote: >> Christian Heimes wrote: >>> On 2015-11-30 12:51, Martin Basti wrote: >>>> >>>> >>>> On 28.11.2015 00:14, Rob Crittenden wrote: >>>>> Martin ?tefany wrote: >>>>>> Hello, >>>>>> >>>>>> I remember experiencing this, but I'm not sure of solution. I think it's >>>>>> related to apache (httpd) and his group. >>>>>> >>>>>> My notes for IPA installation on CentOS 7.x say: >>>>>> >>>>>> # groupadd -g 48 apache >>>>>> # yum -y install ipa-server bind bind-dyndb-ldap >>>>>> # usermod -g apache apache >>>>>> # ipa-server-install... >>>>>> >>>>>> CentOS is somehow not creating group apache for apache user and then >>>>>> assuming root which is then causing problems with apache later. Pre- >>>>>> creating such group before installing httpd and then usermod-ing user >>>>>> apache might solve it. >>>>>> >>>>>> Did you get any warnings while running: >>>>>> # yum install -y ipa-server bind bind-dyndb-ldap ? >>>>>> >>>>>> >>>>>> If possible, try installation from scratch with my notes on fresh >>>>>> system. If not: >>>>>> >>>>>> # systemctl stop apache # if it runs >>>>>> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >>>>>> 48, or use 'groupadd -r apache' instead >>>>>> # usermod -g apache apache >>>>>> # ipa-server-install... >>>>>> >>>>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug >>>>> against Apache to create its own uid/gid, which I'm pretty certain it >>>>> already does. >>>>> >>>>> In any case, dogtag doesn't run in Apache so it would be unlikely to >>>>> blow up in the CA installer. >>>>> >>>>> cating the contents of a directory into one log is not at all helpful, >>>>> especially given that you missed all the important bits in the >>>>> subdirectories beneath it. This is just a mishmash of stuff. We need to >>>>> see /var/log/pki/pki-tomcat/ca/debug. >>>>> >>>>> /var/log/ipaserver-install.log might also be useful to see though it >>>>> probably just records in a more verbose way the fact that pkispawn >>>>> failed. >>>>> >>>>> rob >>>>> >>>> Hello, >>>> >>>> I see in log this error message: >>>> >>>> 2015-11-26 08:41:53 pkidestroy : ERROR ....... >>>> subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', >>>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', >>>> '/etc/pki/pki-tomcat/alias', '-e', >>>> 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', >>>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned >>>> non-zero exit status 6! >>>> >>>> It means that the CA has no been sucessfully uninstalled, and it can >>>> cause issues during installation >>>> PKI bug: >>>> https://fedorahosted.org/pki/ticket/1704 >>>> >>>> Christian may have workaround (CCed) >>> >>> Hi Martin and Martin, >>> >>> last week I have identified an incompatibility between Dogtag's sslget >>> command and Apache HTTP. sslget sends a server name indication during >>> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer >>> versions of Apache HTTP don't accept requests with SNI and without HTTP >>> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log. >>> >>> The simplest workaround is to bypass Apache and talk to Dogtag directly. >>> In order to do bypass the Apache proxy you have to log onto the server. >>> You also have to become root so you can access the NSS database that >>> contains the private key for authentication. Simply copy and paste the >>> sslget command from the log (everything between "Command '[" and "]' >>> returend non-zero exit status 6!"), remove the comma, replace >>> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command >>> should look like: >>> >>> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ... >>> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443' >> >> mod_nss added support for SNI in Fedora 23. It should behave the same >> way as mod_ssl, denying a request that contains an SNI hostname but no >> Host header. >> >> I assume you've filed a bug against dogtag to send a Host header in the >> request? >> >> A better workaround would be to add NSSSNI off to >> /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install >> should work then, or at least get past this sslget error. > > That might explain why the issue hasn't popped up earlier. sslget sets > SNI header without HTTP Host header for a while. Since FreeIPA uses > mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header > before, sslget didn't fail in the past. > > Yes, I have fixed sslget to send a HTTP Host header with hostname and port. > > No, that won't work. You'd have to change the configuration before you > run uninstall. Install still won't work because uninstall was > incomplete. It's still necessary to remove the Service Domain for the CA > from LDAP. The sslget command call removes it. It's also possible to > remove it with ldapremove over ldapi. The entry is in the > cn=CAList,ou=Security Domain,o=ipaca subtree. I'm not sure I follow. You mean my proposed workaround won't work? I think it should because the IPA installer directly tweaks only a few things in nss.conf so if one manually sets NSSSNI then it should be preserved between install/uninstall. I was under the impression this is a fresh install so there is no existing data to deal with. rob From mbasti at redhat.com Mon Nov 30 16:48:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 17:48:31 +0100 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C7D3B.5070506@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> <565C6ADE.4080108@redhat.com> <565C6E2B.6090001@redhat.com> <565C7D3B.5070506@redhat.com> Message-ID: <565C7DDF.4090806@redhat.com> On 30.11.2015 17:45, Rob Crittenden wrote: > Christian Heimes wrote: >> On 2015-11-30 16:27, Rob Crittenden wrote: >>> Christian Heimes wrote: >>>> On 2015-11-30 12:51, Martin Basti wrote: >>>>> >>>>> On 28.11.2015 00:14, Rob Crittenden wrote: >>>>>> Martin ?tefany wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I remember experiencing this, but I'm not sure of solution. I think it's >>>>>>> related to apache (httpd) and his group. >>>>>>> >>>>>>> My notes for IPA installation on CentOS 7.x say: >>>>>>> >>>>>>> # groupadd -g 48 apache >>>>>>> # yum -y install ipa-server bind bind-dyndb-ldap >>>>>>> # usermod -g apache apache >>>>>>> # ipa-server-install... >>>>>>> >>>>>>> CentOS is somehow not creating group apache for apache user and then >>>>>>> assuming root which is then causing problems with apache later. Pre- >>>>>>> creating such group before installing httpd and then usermod-ing user >>>>>>> apache might solve it. >>>>>>> >>>>>>> Did you get any warnings while running: >>>>>>> # yum install -y ipa-server bind bind-dyndb-ldap ? >>>>>>> >>>>>>> >>>>>>> If possible, try installation from scratch with my notes on fresh >>>>>>> system. If not: >>>>>>> >>>>>>> # systemctl stop apache # if it runs >>>>>>> # groupadd -g 48 apache # I use 48 as apache's UID tends to be also >>>>>>> 48, or use 'groupadd -r apache' instead >>>>>>> # usermod -g apache apache >>>>>>> # ipa-server-install... >>>>>>> >>>>>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug >>>>>> against Apache to create its own uid/gid, which I'm pretty certain it >>>>>> already does. >>>>>> >>>>>> In any case, dogtag doesn't run in Apache so it would be unlikely to >>>>>> blow up in the CA installer. >>>>>> >>>>>> cating the contents of a directory into one log is not at all helpful, >>>>>> especially given that you missed all the important bits in the >>>>>> subdirectories beneath it. This is just a mishmash of stuff. We need to >>>>>> see /var/log/pki/pki-tomcat/ca/debug. >>>>>> >>>>>> /var/log/ipaserver-install.log might also be useful to see though it >>>>>> probably just records in a more verbose way the fact that pkispawn >>>>>> failed. >>>>>> >>>>>> rob >>>>>> >>>>> Hello, >>>>> >>>>> I see in log this error message: >>>>> >>>>> 2015-11-26 08:41:53 pkidestroy : ERROR ....... >>>>> subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', >>>>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', >>>>> '/etc/pki/pki-tomcat/alias', '-e', >>>>> 'name="/var/lib/pki/pki-tomcat"&type=CA&list=caList&host=ipa.home&sport=443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove', >>>>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned >>>>> non-zero exit status 6! >>>>> >>>>> It means that the CA has no been sucessfully uninstalled, and it can >>>>> cause issues during installation >>>>> PKI bug: >>>>> https://fedorahosted.org/pki/ticket/1704 >>>>> >>>>> Christian may have workaround (CCed) >>>> Hi Martin and Martin, >>>> >>>> last week I have identified an incompatibility between Dogtag's sslget >>>> command and Apache HTTP. sslget sends a server name indication during >>>> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer >>>> versions of Apache HTTP don't accept requests with SNI and without HTTP >>>> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log. >>>> >>>> The simplest workaround is to bypass Apache and talk to Dogtag directly. >>>> In order to do bypass the Apache proxy you have to log onto the server. >>>> You also have to become root so you can access the NSS database that >>>> contains the private key for authentication. Simply copy and paste the >>>> sslget command from the log (everything between "Command '[" and "]' >>>> returend non-zero exit status 6!"), remove the comma, replace >>>> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command >>>> should look like: >>>> >>>> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ... >>>> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443' >>> mod_nss added support for SNI in Fedora 23. It should behave the same >>> way as mod_ssl, denying a request that contains an SNI hostname but no >>> Host header. >>> >>> I assume you've filed a bug against dogtag to send a Host header in the >>> request? >>> >>> A better workaround would be to add NSSSNI off to >>> /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install >>> should work then, or at least get past this sslget error. >> That might explain why the issue hasn't popped up earlier. sslget sets >> SNI header without HTTP Host header for a while. Since FreeIPA uses >> mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header >> before, sslget didn't fail in the past. >> >> Yes, I have fixed sslget to send a HTTP Host header with hostname and port. >> >> No, that won't work. You'd have to change the configuration before you >> run uninstall. Install still won't work because uninstall was >> incomplete. It's still necessary to remove the Service Domain for the CA >> from LDAP. The sslget command call removes it. It's also possible to >> remove it with ldapremove over ldapi. The entry is in the >> cn=CAList,ou=Security Domain,o=ipaca subtree. > I'm not sure I follow. You mean my proposed workaround won't work? I > think it should because the IPA installer directly tweaks only a few > things in nss.conf so if one manually sets NSSSNI then it should be > preserved between install/uninstall. > > I was under the impression this is a fresh install so there is no > existing data to deal with. > > rob > If I did read logs right, there was ipa-server-installed, CA uninstallation failed and now IPA server install is failing because new CA cannot be installed due the old instance of CA. Martin From cheimes at redhat.com Mon Nov 30 17:22:42 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 30 Nov 2015 18:22:42 +0100 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C7DDF.4090806@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> <565C6ADE.4080108@redhat.com> <565C6E2B.6090001@redhat.com> <565C7D3B.5070506@redhat.com> <565C7DDF.4090806@redhat.com> Message-ID: <565C85E2.9000309@redhat.com> On 2015-11-30 17:48, Martin Basti wrote: > If I did read logs right, there was ipa-server-installed, CA > uninstallation failed and now IPA server install is failing because new > CA cannot be installed due the old instance of CA. Martin, you are right. Daniel didn't mention reinstallation in his initial mail. You and me are aware of the details because we talked to him on IRC. I just asked Daniel on IRC and he confirmed it. Rob couldn't know the fact, hence the misunderstanding. Robert, your workaround fixes uninstallation. But it doesn't fix an already broken system. ipa-server --uninstall leaves the system in an inconsistent state. It removes most of the CA but leaves entries in LDAP ou=Security Domain,o=ipaca. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jstormshak at cccis.com Mon Nov 30 18:34:27 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Mon, 30 Nov 2015 18:34:27 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> <20151124135748.GM9605@redhat.com> Message-ID: Alex/Group --- I?ve implemented the ipa-advise script and authentication worked as expected on the legacy 5.5 client. Although, I continue to get closer, another bump in the road here. Anyone experienced this error and could provide some areas to review to correct it? Please advise ? Thanks for the continual help here !! $ passwd Changing password for user pmoss. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Constraint violation Pre-Encoded passwords are not valid passwd: Permission denied From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak Sent: Tuesday, November 24, 2015 4:40 PM To: Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Alex - Thank you for the details!! For right now, I?m using the IPA Server as a standalone Linux domain controller/server without any AD integration. This allows testing to prove that this could work with a large number of 5.5 clients in the enterprise to date. On the question being proposed ? You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. ANSWER: Yes. I?m trying to achieve full integration with AD but I?m only at the point where I started testing this in a standalone Linux mode. I was trying to see if these legacy 5.5 clients were even possible to configure and to work here as specified. I?ll review the IPA tools for better understanding here. Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Alexander Bokovoy > Date: Tuesday, November 24, 2015 at 7:57 AM To: Jeffrey Stormshak > Cc: Jakub Hrozek >, Rob Crittenden >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Tue, 24 Nov 2015, Jeffrey Stormshak wrote: I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? ipa-advise is a tool on IPA server that provides recipes how to configure different clients for a typical scenarios involving trust to AD. Read the manual for the tool to get more information. For legacy clients where there is no recent enough SSSD to support trust to AD natively, ipa-advise recommends using schema compatibility plugin to expose both IPA and AD users under same LDAP tree. This is what you see in cn=users,cn=compat,dc=example,dc=com. If you see cn=compat in the LDAP base DN, you know you are looking into the compatibility tree. Compatibility tree is handled by a special plugin which combines data from the primary IPA tree (cn=accounts,dc=example,dc=com) and from SSSD on IPA server. It also exposes ou=SUDOers subtree to allow SUDO application to work with sudo rules stored in IPA LDAP (they are not in the same format as SUDO itself expects, thus _compatibility_ subtree). I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? Finally, password changes are not supported in cn=compat subtree. This is simply not implemented by schema compatibility plugin. You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. If you don't need integration with Active Directory, change LDAP base DN in your configuration to cn=accounts,dc=example,dc=com, to point your clients to the primary IPA subtree where all users and groups are available. That subtree is the main one and we do support password changes for DNs in it. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 30 18:54:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Nov 2015 13:54:57 -0500 Subject: [Freeipa-users] CA installation failed on server In-Reply-To: <565C85E2.9000309@redhat.com> References: <1448665185.5479.20.camel@stefany.eu> <5658E3DF.2020503@redhat.com> <565C3857.7000002@redhat.com> <565C45DB.1040605@redhat.com> <565C6ADE.4080108@redhat.com> <565C6E2B.6090001@redhat.com> <565C7D3B.5070506@redhat.com> <565C7DDF.4090806@redhat.com> <565C85E2.9000309@redhat.com> Message-ID: <565C9B81.6030402@redhat.com> Christian Heimes wrote: > On 2015-11-30 17:48, Martin Basti wrote: >> If I did read logs right, there was ipa-server-installed, CA >> uninstallation failed and now IPA server install is failing because new >> CA cannot be installed due the old instance of CA. > > Martin, you are right. Daniel didn't mention reinstallation in his > initial mail. You and me are aware of the details because we talked to > him on IRC. I just asked Daniel on IRC and he confirmed it. Rob couldn't > know the fact, hence the misunderstanding. > > Robert, your workaround fixes uninstallation. But it doesn't fix an > already broken system. ipa-server --uninstall leaves the system in an > inconsistent state. It removes most of the CA but leaves entries in LDAP > ou=Security Domain,o=ipaca. I don't know quite what to say. Any already broken system? The IPA installer isn't (yet) idempotent so any failure installing needs to be uninstalled, corrected, and tried again. There is no powering onwards. Left over data? In a standalone system this is moot because IPA needs to start as a clean slate for a new installation attempt. I really don't see how my workaround made any difference at all in the uninstall since it should just be removing bits not doing anything over LDAP. And in any case, uninstalling the server also wipes out the LDAP server so it's a moot point. rob