Re: [Freeipa-users] freeipa as organizational CA
> Andy, you can install FreeIPA as a sub-CA of your offline root. > Support for creating sub-CAs *within* FreeIPA, under the "main" > FreeIPA CA (which in your case is a sub-CA of your offline root), is not yet > available but I am working on that. But if you only need one CA as a sub-CA > of an offline root, you can use FreeIPA today. > I've got this setup and working with an openssl minted root CA, I've minted a few certs and it all seems to work well enough. I'm trying to sort out what features I might be missing using the FreeIPA implementation in this setup as compared to setting up dogtag, ejbca or looking at the RHCS product. I've tried accessing the dogtag web console and it doesn't work on the IPA server. Thanks! -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa as organizational CA
> > > >If I can get an exclusion for the sub-CA bits, can that be added at a > >later time and just run with a root CA for now? Can it perform all of > >the needs of an org CA outside of an IPA environment? > Not through the IPA interfaces but standard Dogtag is there, with its (albeit > a > bit cumbersome) web UI. So I guess you could do what IPA doesn't allow via > that one, though there will be no support for these functions. > What functions does IPA not allow? -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] freeipa as organizational CA
Is freeipa in RHEL7.2 able to be used as an organizational CA these days? I have a requirement to set one up and like the IPA interface and tools, but can't sort out the current state in 4.2 to decipher whether this is possible, or even reasonable to try. I need to setup an org sub CA with an offline root CA The dogtag pki-ca in 7.2 appears to be missing some pieces, none of the management themes seem to be available and the console utilities are hit and miss, so I'm looking at this possibility. Seems like overkill but thought I'd toss the idea around. Thanks! -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] lock table errors
> On 02/23/2016 05:10 PM, Andy Thompson wrote: > >>>> On 02/23/2016 03:02 PM, Andy Thompson wrote: > >>>>> Came across one of my replicas this morning with the following in > >>>>> the error log > >>>>> > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - > _entryrdn_delete_key: > >>>>> Deleting C1 failed; Cannot allocate memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>>>> 1031, err=12 Cannot allocate memory > >>>>> [20/Feb/2016:17:23:38 -0500] - > >>>>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed > >> (12) > >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328662 (rc: 1) > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > >>>>> Failed to position cursor at the key: 1328666: Cannot allocate > >>>>> memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - > _entryrdn_delete_key: > >>>>> Failed to position cursor at the key: 1328666: Cannot allocate > >>>>> memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>>>> 1031, err=12 Cannot allocate memory > >>>>> [20/Feb/2016:17:23:38 -0500] - > >>>>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed > >> (12) > >>>>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog > >>>>> program > >>>>> - _cl5CompactDBs: failed to compact > >>>>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > >>>>> memory > >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328663 (rc: 1) > >>>>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: > >>>>> 1] > >>>> No original_tombstone for changenumber=1330335,cn=changelog!! > >>>>> And then nothing. Was troubleshooting some clients that were > >>>>> having > >>>> issues resolving some trusted domain users. > >>>>> I restarted IPA and it rolled through a few thousand missing > >>>>> change records > >>>>> > >>>>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328696 (rc: 32) > >>>>> > >>>>> Any thoughts as to what might have caused the lock table errors? > >>>> in BerkeleyDB this means that the number of pages which would have > >>>> to be locked in one transaction exceeds the configured number of > locks. > >>>> This could happen if eg a large group is deleted and for each > >>>> member of the group inside the same transaction the memberof > >>>> attribute has to be modified > >>> Are there any configuration options to increase that setting? And > >>> would it > >> have caused the replica to become unresponsive? > >> you can change > >> > >> nsslapd-db-locks > >> > >> in the entry: > >> > >> dn: cn=config,cn=ldbm database,cn=plugins,cn=config > >> > >> yes. in that state it would not process updates, the txn should be > >> finally aborted and the system should recover,but .. > > Is there any rule of thumb or anything I can look at to get an idea of what > > I > should increase that to or should it even be necessary? > > > > The current setting has a default of 1 > > > > cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config > > > > currently shows > > > > nsslapd-db-current-locks: 82 > > > > What might cause that to spike up that significantly to deplete the locks? > That's a pretty huge jump. > I have given you an example of what operation could use a high number of > page locks, to find out what was going on in your case would require to > investigate which operations were active when the problem started, what > the entries modified added looked like .. > > Right, is there anything I can look at now that might give me any useful information? Access log looks pretty normal around that time. At the time the error occurred there would have been very little going on in the system other than internal processing and normal user access. My environment is almost entirely an AD trust setup with HBAC and sudo. There are very few users and groups in the local database for a large transaction to even be in the scope of possible that I can think of. I'm checking with the windows group to see if there was anything out of the ordinary going on in AD at the time but there were no changes scheduled. Is it possible that AD changes could be suspect? -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] lock table errors
> >> On 02/23/2016 03:02 PM, Andy Thompson wrote: > >>> Came across one of my replicas this morning with the following in > >>> the error log > >>> > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > >>> Deleting C1 failed; Cannot allocate memory(12) > >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>> 1031, err=12 Cannot allocate memory > >>> [20/Feb/2016:17:23:38 -0500] - > >>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed > (12) > >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328662 (rc: 1) > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > >>> Failed to position cursor at the key: 1328666: Cannot allocate > >>> memory(12) > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > >>> Failed to position cursor at the key: 1328666: Cannot allocate > >>> memory(12) > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>> 1031, err=12 Cannot allocate memory > >>> [20/Feb/2016:17:23:38 -0500] - > >>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed > (12) > >>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog > >>> program > >>> - _cl5CompactDBs: failed to compact > >>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > >>> memory > >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328663 (rc: 1) > >>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: > >>> 1] > >> No original_tombstone for changenumber=1330335,cn=changelog!! > >>> And then nothing. Was troubleshooting some clients that were having > >> issues resolving some trusted domain users. > >>> I restarted IPA and it rolled through a few thousand missing change > >>> records > >>> > >>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328696 (rc: 32) > >>> > >>> Any thoughts as to what might have caused the lock table errors? > >> in BerkeleyDB this means that the number of pages which would have to > >> be locked in one transaction exceeds the configured number of locks. > >> This could happen if eg a large group is deleted and for each member > >> of the group inside the same transaction the memberof attribute has > >> to be modified > > > > Are there any configuration options to increase that setting? And would it > have caused the replica to become unresponsive? > you can change > > nsslapd-db-locks > > in the entry: > > dn: cn=config,cn=ldbm database,cn=plugins,cn=config > > yes. in that state it would not process updates, the txn should be finally > aborted and the system should recover,but .. Is there any rule of thumb or anything I can look at to get an idea of what I should increase that to or should it even be necessary? The current setting has a default of 1 cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config currently shows nsslapd-db-current-locks: 82 What might cause that to spike up that significantly to deplete the locks? That's a pretty huge jump. Running 389-ds-base-1.3.4.0-26.el7_2.x86_64 -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] lock table errors
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, February 23, 2016 9:31 AM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] lock table errors > > > On 02/23/2016 03:02 PM, Andy Thompson wrote: > > Came across one of my replicas this morning with the following in the > > error log > > > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > > Deleting C1 failed; Cannot allocate memory(12) > > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > > 1031, err=12 Cannot allocate memory > > [20/Feb/2016:17:23:38 -0500] - > > index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed (12) > > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328662 (rc: 1) > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > > Failed to position cursor at the key: 1328666: Cannot allocate > > memory(12) > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > > Failed to position cursor at the key: 1328666: Cannot allocate > > memory(12) > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > > 1031, err=12 Cannot allocate memory > > [20/Feb/2016:17:23:38 -0500] - > > index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed (12) > > [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog program > > - _cl5CompactDBs: failed to compact > > 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > > memory > > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328663 (rc: 1) > > [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: 1] > No original_tombstone for changenumber=1330335,cn=changelog!! > > > > And then nothing. Was troubleshooting some clients that were having > issues resolving some trusted domain users. > > > > I restarted IPA and it rolled through a few thousand missing change > > records > > > > 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328696 (rc: 32) > > > > Any thoughts as to what might have caused the lock table errors? > in BerkeleyDB this means that the number of pages which would have to be > locked in one transaction exceeds the configured number of locks. This could > happen if eg a large group is deleted and for each member of the group > inside the same transaction the memberof attribute has to be modified > > Are there any configuration options to increase that setting? And would it have caused the replica to become unresponsive? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa client in DMZ
> -Original Message- > From: Baird, Josh [mailto:jba...@follett.com] > Sent: Tuesday, February 2, 2016 9:13 AM > To: Andy Thompson <andy.thomp...@e-tcc.com>; freeipa- > us...@redhat.com > Subject: RE: freeipa client in DMZ > > I believe the sssd clients will need to communicate directly with your AD > domain controllers, unfortunately. I wish there was a clean way around this, > since we have a ton of DC's in our HUB site, and I don't really want to poke > holes in the firewall(s) for all of them. > > Would someone from sssd/IPA mind chiming in here? What exactly needs to > be open? What DNS record can we query to get the exact list of DC's that > need to be available? Is there a way to restrict the list of domain > controllers > that certain sssd clients need to communicate with (for scenarios like this)? > > Thanks, > > Josh > > > -Original Message- > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > > boun...@redhat.com] On Behalf Of Andy Thompson > > Sent: Tuesday, February 02, 2016 9:04 AM > > To: freeipa-users@redhat.com > > Subject: [Freeipa-users] freeipa client in DMZ > > > > Are ports required to be open for a freeipa client in a DMZ to the AD > > DCs for trusted users to login? I've got everything open to the IPA > > servers required and can lookup users and sudo rules and such but > > trusted users are not able to login. > > > > Thanks > > > > -andy > > > > Going through my firewall logs it appears kerberos needs opened to the DCs at a minimum although I dropped 464 in there as well. Once I opened that up I was able to authenticate I'm not much of an AD guy so I don't know if there is a way to limit the servers accessed within AD. In my environment I had to setup separate DNS servers for the AD domain due to the environment setup so I could control it that way by removing DC records from that DNS environment. My thought is that it relies on the _kerberos._tcp srv records -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] freeipa client in DMZ
Are ports required to be open for a freeipa client in a DMZ to the AD DCs for trusted users to login? I've got everything open to the IPA servers required and can lookup users and sudo rules and such but trusted users are not able to login. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system
> >> > >>-Original Message- > >>From: freeipa-users-boun...@redhat.com <mailto:freeipa- > >> users-boun...@redhat.com> [mailto:freeipa-users- > >>boun...@redhat.com <mailto:boun...@redhat.com> ] On > Behalf Of Petr > >> Spacek > >>Sent: Thursday, December 3, 2015 3:04 AM > >>To: freeipa-users@redhat.com <mailto:freeipa- > us...@redhat.com> > >>Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd > hanging > >> system > >> > >>On 2.12.2015 22:02, Alexander Bokovoy wrote: > >> > >>On Wed, 02 Dec 2015, Andy Thompson wrote: > >> > >>Since updating to RHEL 7.2 I've got issues with > ns-slapd hanging > >> the > >>system up after a period of time. The > directory becomes > >> unresponsive > >>to searches or any connections. After a > restart I see > >> > >>[02/Dec/2015:15:27:41 -0500] - slapd started. > >> Listening on All > >>Interfaces port 389 for LDAP requests > >>[02/Dec/2015:15:27:41 -0500] - Listening on > All Interfaces port > >> 636 > >>for LDAPS requests > >>[02/Dec/2015:15:27:41 -0500] - Listening on > >>/var/run/slapd-MHBENP-LIN.socket for > LDAPI requests > >>[02/Dec/2015:15:27:44 -0500] > >> NSMMReplicationPlugin - > >>agmt="cn=meTomdhixnpipa02.mhbenp.lin" > >> (mdhixnpipa02:389): > >> > >>Replication > >> > >>bind with GSSAPI auth resumed > >>[02/Dec/2015:15:27:47 -0500] > >> NSMMReplicationPlugin - replication keep > >>alive entry
Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Rich Megginson > Sent: Thursday, December 3, 2015 4:44 PM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system > > On 12/03/2015 08:33 AM, Andy Thompson wrote: > > > > > > -Original Message- > From: freeipa-users-boun...@redhat.com <mailto:freeipa- > users-boun...@redhat.com> [mailto:freeipa-users- > boun...@redhat.com <mailto:boun...@redhat.com> ] On > Behalf Of Petr Spacek > Sent: Thursday, December 3, 2015 3:04 AM > To: freeipa-users@redhat.com <mailto:freeipa- > us...@redhat.com> > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd > hanging system > > On 2.12.2015 22:02, Alexander Bokovoy wrote: > > On Wed, 02 Dec 2015, Andy Thompson wrote: > > Since updating to RHEL 7.2 I've got issues with > ns-slapd hanging the > system up after a period of time. The > directory becomes unresponsive > to searches or any connections. After a > restart I see > > [02/Dec/2015:15:27:41 -0500] - slapd started. > Listening on All > Interfaces port 389 for LDAP requests > [02/Dec/2015:15:27:41 -0500] - Listening on > All Interfaces port 636 > for LDAPS requests > [02/Dec/2015:15:27:41 -0500] - Listening on > /var/run/slapd-MHBENP-LIN.socket for > LDAPI requests > [02/Dec/2015:15:27:44 -0500] > NSMMReplicationPlugin - > agmt="cn=meTomdhixnpipa02.mhbenp.lin" > (mdhixnpipa02:389): > > Replication > > bind with GSSAPI auth resumed > [02/Dec/2015:15:27:47 -0500] > NSMMReplicationPlugin - replication keep > alive entry
Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Petr Spacek > Sent: Thursday, December 3, 2015 3:04 AM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system > > On 2.12.2015 22:02, Alexander Bokovoy wrote: > > On Wed, 02 Dec 2015, Andy Thompson wrote: > >> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the > >> system up after a period of time. The directory becomes unresponsive > >> to searches or any connections. After a restart I see > >> > >> [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All > >> Interfaces port 389 for LDAP requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 > >> for LDAPS requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on > >> /var/run/slapd-MHBENP-LIN.socket for LDAPI requests > >> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - > >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): > Replication > >> bind with GSSAPI auth resumed > >> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep > >> alive entry
[Freeipa-users] backup/restore best practices
What does everyone do for backup/restore of their IPA infrastructure? I've read over the backup and restore on freeipa.org just want some real world application out there. Right now all of our backups are done at the SAN level. We snap the SAN aggregate containing the VMs and have those snaps available to roll back to. I'm not sure how consistent those backups might end up being at the end of the day and I've never had to roll back in the environment to test or have an environment to test on that level. -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Hoffmaster, John > Sent: Monday, October 12, 2015 3:46 PM > To: freeipa-users@redhat.com > Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question > > Hi, > > The company I work for uses AD 2008R2 DC to resolve requests for > Unix/Linux servers in various environments, under one domain > example.com, with the Realm EXAMPLE.COM ? > > Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a > name server and forwarding all DNS requests to the windows DC's and still > keep everything in the example.com domain without creating a child domain > like ipa.example.com ? > > http://www.freeipa.org/page/Active_Directory_trust_setup > > Add for RedHat 7, use hostnamectl set-hostname ipa.example.com > > and > change the install IPA server command to > > ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - > -realm=example.com --setup-dns --forwarder=AD_ipaddress > > Thanks, > No. The IPA domain has to be different than the AD domain. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> On 09/30/2015 09:04 PM, Andy Thompson wrote: > >> On Wed, Sep 30, 2015 at 12:17:22PM +, Andy Thompson wrote: > >>>> On 09/21/2015 10:42 PM, Andy Thompson wrote: > >>>>>> On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote: > >>>>>>>> -Original Message- > >>>>>>>> From: Jakub Hrozek [mailto:jhro...@redhat.com] > >>>>>>>> Sent: Monday, September 21, 2015 3:29 PM > >>>>>>>> To: Andy Thompson <andy.thomp...@e-tcc.com> > >>>>>>>> Cc: freeipa-users@redhat.com; pbrez...@redhat.com > >>>>>>>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > >>>>>>>> > >>>>>>>> On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson > wrote: > >>>>>>>>>> > >>>>>>>>>> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson > >> wrote: > >>>>>>>>>>> I've narrowed it down a bit doing some testing. The sudo > >>>>>>>>>>> rules work when > >>>>>>>>>> I remove the user group restriction from them. My sudo rules > >>>>>>>>>> all have my ad groups in the rule > >>>>>>>>>>> > >>>>>>>>>>> Rule name: ad_linux_admins > >>>>>>>>>>> Enabled: TRUE > >>>>>>>>>>> Host category: all > >>>>>>>>>>> Command category: all > >>>>>>>>>>> RunAs User category: all > >>>>>>>>>>> RunAs Group category: all > >>>>>>>>>>> User Groups: ad_linux_admins <- if I remove this then > >>>>>>>>>>> the rule gets > >>>>>>>>>> applied > >>>>>>>>>> > >>>>>>>>>> Nice catch. Is the group visible after you login and run id? > >>>>>>>>>> > >>>>>>>>>> What is the exact IPA server version? > >>>>>>>>> > >>>>>>>>> Ok I also figured out if I rename my AD groups to match my IPA > >>>>>>>>> groups then > >>>>>>>> the sudo rules are applied. > >>>>>>>>> > >>>>>>>>> I tested a couple things though, if I put a rule in the local > >>>>>>>>> sudoers file on a server running sssd 1.11 > >>>>>>>>> > >>>>>>>>> %@ "sudo commands" > >>>>>>>>> > >>>>>>>>> That rule was not applied. If I remove the then > >>>>>>>>> the rule got > >>>>>>>> applied. > >>>>>>>>> > >>>>>>>>> On a server running sssd 1.12 that rule works, but does not > >>>>>>>>> work if I > >>>>>>>> remove the . And none of the IPA sudo rules work. > >>>>>>>> So something changed with the domain suffix between versions it > >>>>>>>> would appear. > >>>>>>>>> > >>>>>>>>> They key to making the IPA sudo rules work in 1.12 is to > >>>>>>>>> remove the > >>>>>>>> default_domain_suffix setting in the sssd.conf, but that's not > >>>>>>>> an option in my environment. > >>>>>>>>> > >>>>>>>>> So all the moving parts together, it appears that having AD > >>>>>>>>> groups with a different name than the IPA groups in > >>>>>>>>> conjunction with the default_domain_suffix setting breaks > >>>>>>>>> things > >> right now in 1.12. > >>>>>>>>> Appears since I renamed the ad group to match then the rule > >>>>>>>>> without a domain suffix will get matched now > >>>>>>>> > >>>>>>>> Hello Andy, > >>>>>>>> > >>>>>>>> I'm sorry for the constant delays, but I was busy with some > >>>>>>>
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> On Wed, Sep 30, 2015 at 12:17:22PM +0000, Andy Thompson wrote: > > > On 09/21/2015 10:42 PM, Andy Thompson wrote: > > > >> On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote: > > > >>>> -Original Message- > > > >>>> From: Jakub Hrozek [mailto:jhro...@redhat.com] > > > >>>> Sent: Monday, September 21, 2015 3:29 PM > > > >>>> To: Andy Thompson <andy.thomp...@e-tcc.com> > > > >>>> Cc: freeipa-users@redhat.com; pbrez...@redhat.com > > > >>>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > > >>>> > > > >>>> On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote: > > > >>>>>> > > > >>>>>> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson > wrote: > > > >>>>>>> I've narrowed it down a bit doing some testing. The sudo > > > >>>>>>> rules work when > > > >>>>>> I remove the user group restriction from them. My sudo rules > > > >>>>>> all have my ad groups in the rule > > > >>>>>>> > > > >>>>>>>Rule name: ad_linux_admins > > > >>>>>>>Enabled: TRUE > > > >>>>>>>Host category: all > > > >>>>>>>Command category: all > > > >>>>>>>RunAs User category: all > > > >>>>>>>RunAs Group category: all > > > >>>>>>>User Groups: ad_linux_admins <- if I remove this then > > > >>>>>>> the rule gets > > > >>>>>> applied > > > >>>>>> > > > >>>>>> Nice catch. Is the group visible after you login and run id? > > > >>>>>> > > > >>>>>> What is the exact IPA server version? > > > >>>>> > > > >>>>> Ok I also figured out if I rename my AD groups to match my IPA > > > >>>>> groups then > > > >>>> the sudo rules are applied. > > > >>>>> > > > >>>>> I tested a couple things though, if I put a rule in the local > > > >>>>> sudoers file on a server running sssd 1.11 > > > >>>>> > > > >>>>> %@ "sudo commands" > > > >>>>> > > > >>>>> That rule was not applied. If I remove the then > > > >>>>> the rule got > > > >>>> applied. > > > >>>>> > > > >>>>> On a server running sssd 1.12 that rule works, but does not > > > >>>>> work if I > > > >>>> remove the . And none of the IPA sudo rules work. > > > >>>> So something changed with the domain suffix between versions it > > > >>>> would appear. > > > >>>>> > > > >>>>> They key to making the IPA sudo rules work in 1.12 is to > > > >>>>> remove the > > > >>>> default_domain_suffix setting in the sssd.conf, but that's not > > > >>>> an option in my environment. > > > >>>>> > > > >>>>> So all the moving parts together, it appears that having AD > > > >>>>> groups with a different name than the IPA groups in > > > >>>>> conjunction with the default_domain_suffix setting breaks things > right now in 1.12. > > > >>>>> Appears since I renamed the ad group to match then the rule > > > >>>>> without a domain suffix will get matched now > > > >>>> > > > >>>> Hello Andy, > > > >>>> > > > >>>> I'm sorry for the constant delays, but I was busy with some > > > >>>> trust-related fixes lately. > > > >>>> > > > >>>> Did you have a chance to confirm that just swapping sssd /on > > > >>>> the client/ while keeping the same version on the server fixes > > > >>>> the issue for > > > >> you? > > > >>>> > > > >>>> Pavel (CC), can you help me out here, please? I have the setup > > > >>>> ready on my machine, so tomor
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> On 09/21/2015 10:42 PM, Andy Thompson wrote: > >> On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote: > >>>> -Original Message- > >>>> From: Jakub Hrozek [mailto:jhro...@redhat.com] > >>>> Sent: Monday, September 21, 2015 3:29 PM > >>>> To: Andy Thompson <andy.thomp...@e-tcc.com> > >>>> Cc: freeipa-users@redhat.com; pbrez...@redhat.com > >>>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > >>>> > >>>> On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote: > >>>>>> > >>>>>> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > >>>>>>> I've narrowed it down a bit doing some testing. The sudo rules > >>>>>>> work when > >>>>>> I remove the user group restriction from them. My sudo rules all > >>>>>> have my ad groups in the rule > >>>>>>> > >>>>>>>Rule name: ad_linux_admins > >>>>>>>Enabled: TRUE > >>>>>>>Host category: all > >>>>>>>Command category: all > >>>>>>>RunAs User category: all > >>>>>>>RunAs Group category: all > >>>>>>>User Groups: ad_linux_admins <- if I remove this then the > >>>>>>> rule gets > >>>>>> applied > >>>>>> > >>>>>> Nice catch. Is the group visible after you login and run id? > >>>>>> > >>>>>> What is the exact IPA server version? > >>>>> > >>>>> Ok I also figured out if I rename my AD groups to match my IPA > >>>>> groups then > >>>> the sudo rules are applied. > >>>>> > >>>>> I tested a couple things though, if I put a rule in the local > >>>>> sudoers file on a server running sssd 1.11 > >>>>> > >>>>> %@ "sudo commands" > >>>>> > >>>>> That rule was not applied. If I remove the then the > >>>>> rule got > >>>> applied. > >>>>> > >>>>> On a server running sssd 1.12 that rule works, but does not work > >>>>> if I > >>>> remove the . And none of the IPA sudo rules work. So > >>>> something changed with the domain suffix between versions it would > >>>> appear. > >>>>> > >>>>> They key to making the IPA sudo rules work in 1.12 is to remove > >>>>> the > >>>> default_domain_suffix setting in the sssd.conf, but that's not an > >>>> option in my environment. > >>>>> > >>>>> So all the moving parts together, it appears that having AD groups > >>>>> with a different name than the IPA groups in conjunction with the > >>>>> default_domain_suffix setting breaks things right now in 1.12. > >>>>> Appears since I renamed the ad group to match then the rule > >>>>> without a domain suffix will get matched now > >>>> > >>>> Hello Andy, > >>>> > >>>> I'm sorry for the constant delays, but I was busy with some > >>>> trust-related fixes lately. > >>>> > >>>> Did you have a chance to confirm that just swapping sssd /on the > >>>> client/ while keeping the same version on the server fixes the > >>>> issue for > >> you? > >>>> > >>>> Pavel (CC), can you help me out here, please? I have the setup > >>>> ready on my machine, so tomorrow we can take a look and experiment > >>>> (I can give you access to my environment via tmate maybe..), but I > >>>> wasn't able to reproduce the issue locally yet. > >>> > >>> It's fine I understand the backlog. > >>> > >>> I was not able to backrev the sssd due to dependency issues. I > >>> tried > >> downgrading all the dependencies and got in a loop and stopped > >> trying. Are there any tricks you can think of to downgrade the sssd > cleanly? > >>> > >>> -andy > >>> > >> > >> What failures are you getting? I normally just download all \*sss\* > >> packages and then downgrade with rpm -U --oldpackage. > > > >
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Pavel Reichl > Sent: Thursday, September 24, 2015 5:18 AM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > Hello Andy, > > I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right? > > What version of SSSD do you run on ipa server? > The servers are running sssd-1.12.2-58.el7_1.14.x86_64 -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd public socket error
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Wednesday, September 23, 2015 4:54 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] sssd public socket error
>
> On Wed, Sep 23, 2015 at 06:03:45PM +, Andy Thompson wrote:
> > On one of my servers I'm getting
> >
> > Sep 23 13:35:07 mdhixuatisamw03 sshd[8136]: pam_unix(sshd:session):
> > session opened for user user by (uid=0) Sep 23 13:35:07 mdhixuatisamw03
> sshd[8164]: pam_sss(sshd:setcred): Request to sssd failed. Public socket has
> wrong ownership or permissions.
> >
> > Authentication still works but group name lookups fail on the server.
> >
> > Haven't been able to track down yet what config is different on this server
> and I can't find any information on this, anyone have any thoughts?
>
> The code is:
> 860 statret = stat(SSS_PAM_SOCKET_NAME, _buf);
> 861 if (statret != 0) {
> 862 ret = PAM_SERVICE_ERR;
> 863 goto out;
> 864 }
> 865 if ( ! (stat_buf.st_uid == 0 &&
> 866 stat_buf.st_gid == 0 &&
> 867 S_ISSOCK(stat_buf.st_mode) &&
> 868 (stat_buf.st_mode & ~S_IFMT) == 0666 )) {
> 869 *errnop = ESSS_BAD_PUB_SOCKET;
> 870 ret = PAM_SERVICE_ERR;
> 871 goto out;
> 872 }
> 873
>
> I would compare:
> ls -lR /var/lib/sss/pipes/
>
> on a working or a non-working server. The public PAM socket
> (/var/lib/sss/pipes/pam) should be there and should have permission 0666.
>
> Also check AVC denials.
>
It was file perms on those files. Thanks for the pointer.
-andy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA server failover
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, September 24, 2015 1:17 AM
> To: Andy Thompson <andy.thomp...@e-tcc.com>
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA server failover
>
> On Wed, 23 Sep 2015, Andy Thompson wrote:
> >I've got all of my environments setup with two IPA servers. I'm
> >fighting intermittent problems with krb5kdc crashing on them in all of
> >my environments and I've opened a ticket with Redhat on that. What I
> >can't figure out though is why the clients will not fail over to the
> >second functioning server in the domain
> >
> >My sssd.conf files are all pretty generic from the install with minimal
> >modification to add a couple settings.
> >
> >[domain/mhbe.lin]
> >
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = mhbe.lin
> >id_provider = ipa
> >auth_provider = ipa
> >access_provider = ipa
> >ipa_hostname = mdhixproddb01.mhbe.lin
> >chpass_provider = ipa
> >ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
> >/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services =
> >nss, sudo, pam, ssh config_file_version = 2
> >
> >domains = mhbe.lin
> >[nss]
> >default_shell = /bin/bash
> >homedir_substring = /home
> >debug_level = 7
> >[pam]
> >
> >[sudo]
> >
> >[autofs]
> >
> >[ssh]
> >
> >[pac]
> >
> >[ifp]
> >
> >I thought the _srv_ would force it to use dns and both servers are
> >round robined when digging the _kerberos records from DNS. So I don't
> >understand why it's not working
> ipa_server is for SSSD tasks using LDAP server. Kerberos libraries are using
> /etc/krb5.conf for hints where to find KDCs.
>
> A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing 'kdc = '
> for specific realm would cause Kerberos clients to do DNS discovery using
> SRV records.
>
Here are the contents of my krb conf with everything set to lookup and it
doesn't appear to be working.
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MHBE.LIN
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
[realms]
MHBE.LIN = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mhbe.lin = MHBE.LIN
mhbe.lin = MHBE.LIN
> If multiple 'kdc = ...' values are specified in the realm definition, Kerberos
> clients will fall over to the next one in the list in case of a failure.
>
> When ipa-client-install is run, we configure krb5.conf without explicit KDCs
> if
> DNS discovery of Kerberos was successful which should take care of SRV
> record-based discovery of KDCs.
> --
> / Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
Ok it will take me a while to get my test environment setup to match what I have in prod currently and I can do some testing at that point in time. -andy From: Pavel Reichl <prei...@redhat.com> Sent: Thursday, September 24, 2015 9:43 AM To: Andy Thompson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo On 09/24/2015 02:50 PM, Andy Thompson wrote: >> -Original Message- >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- >> boun...@redhat.com] On Behalf Of Pavel Reichl >> Sent: Thursday, September 24, 2015 5:18 AM >> To: freeipa-users@redhat.com >> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo >> >> Hello Andy, >> >> I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right? >> >> What version of SSSD do you run on ipa server? >> > > The servers are running > > sssd-1.12.2-58.el7_1.14.x86_64 > > -andy > Thanks, I prepared a scratch build containing patches for https://fedorahosted.org/sssd/ticket/2633 that could be fix your problems. Please consider installing the build on you ipa server but please avoid using it in production environment. Thanks! https://copr.fedoraproject.org/coprs/preichl/fix_ext_grp/ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA server failover
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Petr Spacek
> Sent: Thursday, September 24, 2015 9:50 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA server failover
>
> On 24.9.2015 15:29, Alexander Bokovoy wrote:
> > On Thu, 24 Sep 2015, Andy Thompson wrote:
> >>> -Original Message-
> >>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> >>> Sent: Thursday, September 24, 2015 1:17 AM
> >>> To: Andy Thompson <andy.thomp...@e-tcc.com>
> >>> Cc: freeipa-users@redhat.com
> >>> Subject: Re: [Freeipa-users] IPA server failover
> >>>
> >>> On Wed, 23 Sep 2015, Andy Thompson wrote:
> >>> >I've got all of my environments setup with two IPA servers. I'm
> >>> >fighting intermittent problems with krb5kdc crashing on them in all
> >>> >of my environments and I've opened a ticket with Redhat on that.
> >>> >What I can't figure out though is why the clients will not fail
> >>> >over to the second functioning server in the domain
> >>> >
> >>> >My sssd.conf files are all pretty generic from the install with
> >>> >minimal modification to add a couple settings.
> >>> >
> >>> >[domain/mhbe.lin]
> >>> >
> >>> >cache_credentials = True
> >>> >krb5_store_password_if_offline = True ipa_domain = mhbe.lin
> >>> >id_provider = ipa auth_provider = ipa access_provider = ipa
> >>> >ipa_hostname = mdhixproddb01.mhbe.lin chpass_provider = ipa
> >>> >ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
> >>> >/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services
> >>> >= nss, sudo, pam, ssh config_file_version = 2
> >>> >
> >>> >domains = mhbe.lin
> >>> >[nss]
> >>> >default_shell = /bin/bash
> >>> >homedir_substring = /home
> >>> >debug_level = 7
> >>> >[pam]
> >>> >
> >>> >[sudo]
> >>> >
> >>> >[autofs]
> >>> >
> >>> >[ssh]
> >>> >
> >>> >[pac]
> >>> >
> >>> >[ifp]
> >>> >
> >>> >I thought the _srv_ would force it to use dns and both servers are
> >>> >round robined when digging the _kerberos records from DNS. So I
> >>> >don't understand why it's not working
> >>> ipa_server is for SSSD tasks using LDAP server. Kerberos libraries
> >>> are using /etc/krb5.conf for hints where to find KDCs.
> >>>
> >>> A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing
> 'kdc = '
> >>> for specific realm would cause Kerberos clients to do DNS discovery
> >>> using SRV records.
> >>>
> >>
> >> Here are the contents of my krb conf with everything set to lookup
> >> and it doesn't appear to be working.
> >>
> >> includedir /var/lib/sss/pubconf/krb5.include.d/
> >>
> >> [libdefaults]
> >> default_realm = MHBE.LIN
> >> dns_lookup_realm = true
> >> dns_lookup_kdc = true
> >> rdns = false
> >> ticket_lifetime = 24h
> >> forwardable = yes
> >> udp_preference_limit = 0
> >>
> >>
> >> [realms]
> >> MHBE.LIN = {
> >>pkinit_anchors = FILE:/etc/ipa/ca.crt
> >>
> >> }
> >>
> >>
> >> [domain_realm]
> >> .mhbe.lin = MHBE.LIN
> >> mhbe.lin = MHBE.LIN
> > I bet you have SSSD supplying you KDC info in
> > /var/lib/sss/pubconf/kdcinfo.MHBE.LIN via
> > /usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
> >
> > You can add 'krb5_use_kdcinfo = false' to sssd.conf (domain section),
> > see details in sssd-krb5(5).
>
I will look into adding this setting. Why is this not the default
configuration by the client install?
> Also, I would recommend you to check SRV records in DNS:
>
> $ dig _kerberos._udp.mhbe.lin SRV
>
> It should list both servers (with non-zero priority).
>
Ok both servers are in there but they have a zero priority. Those are the
default records added by the install.
-andy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] sssd public socket error
On one of my servers I'm getting Sep 23 13:35:07 mdhixuatisamw03 sshd[8136]: pam_unix(sshd:session): session opened for user user by (uid=0) Sep 23 13:35:07 mdhixuatisamw03 sshd[8164]: pam_sss(sshd:setcred): Request to sssd failed. Public socket has wrong ownership or permissions. Authentication still works but group name lookups fail on the server. Haven't been able to track down yet what config is different on this server and I can't find any information on this, anyone have any thoughts? Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] IPA server failover
I've got all of my environments setup with two IPA servers. I'm fighting intermittent problems with krb5kdc crashing on them in all of my environments and I've opened a ticket with Redhat on that. What I can't figure out though is why the clients will not fail over to the second functioning server in the domain My sssd.conf files are all pretty generic from the install with minimal modification to add a couple settings. [domain/mhbe.lin] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = mhbe.lin id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mdhixproddb01.mhbe.lin chpass_provider = ipa ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert = /etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services = nss, sudo, pam, ssh config_file_version = 2 domains = mhbe.lin [nss] default_shell = /bin/bash homedir_substring = /home debug_level = 7 [pam] [sudo] [autofs] [ssh] [pac] [ifp] I thought the _srv_ would force it to use dns and both servers are round robined when digging the _kerberos records from DNS. So I don't understand why it's not working Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > > I've narrowed it down a bit doing some testing. The sudo rules work when > I remove the user group restriction from them. My sudo rules all have my ad > groups in the rule > > > > Rule name: ad_linux_admins > > Enabled: TRUE > > Host category: all > > Command category: all > > RunAs User category: all > > RunAs Group category: all > > User Groups: ad_linux_admins <- if I remove this then the rule gets > applied > > Nice catch. Is the group visible after you login and run id? > > What is the exact IPA server version? Ok I also figured out if I rename my AD groups to match my IPA groups then the sudo rules are applied. I tested a couple things though, if I put a rule in the local sudoers file on a server running sssd 1.11 %@ "sudo commands" That rule was not applied. If I remove the then the rule got applied. On a server running sssd 1.12 that rule works, but does not work if I remove the . And none of the IPA sudo rules work. So something changed with the domain suffix between versions it would appear. They key to making the IPA sudo rules work in 1.12 is to remove the default_domain_suffix setting in the sssd.conf, but that's not an option in my environment. So all the moving parts together, it appears that having AD groups with a different name than the IPA groups in conjunction with the default_domain_suffix setting breaks things right now in 1.12. Appears since I renamed the ad group to match then the rule without a domain suffix will get matched now -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> -Original Message- > From: Jakub Hrozek [mailto:jhro...@redhat.com] > Sent: Monday, September 21, 2015 3:29 PM > To: Andy Thompson <andy.thomp...@e-tcc.com> > Cc: freeipa-users@redhat.com; pbrez...@redhat.com > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote: > > > > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > > > > I've narrowed it down a bit doing some testing. The sudo rules > > > > work when > > > I remove the user group restriction from them. My sudo rules all > > > have my ad groups in the rule > > > > > > > > Rule name: ad_linux_admins > > > > Enabled: TRUE > > > > Host category: all > > > > Command category: all > > > > RunAs User category: all > > > > RunAs Group category: all > > > > User Groups: ad_linux_admins <- if I remove this then the rule > > > > gets > > > applied > > > > > > Nice catch. Is the group visible after you login and run id? > > > > > > What is the exact IPA server version? > > > > Ok I also figured out if I rename my AD groups to match my IPA groups then > the sudo rules are applied. > > > > I tested a couple things though, if I put a rule in the local sudoers > > file on a server running sssd 1.11 > > > > %@ "sudo commands" > > > > That rule was not applied. If I remove the then the rule got > applied. > > > > On a server running sssd 1.12 that rule works, but does not work if I > remove the . And none of the IPA sudo rules work. So > something changed with the domain suffix between versions it would > appear. > > > > They key to making the IPA sudo rules work in 1.12 is to remove the > default_domain_suffix setting in the sssd.conf, but that's not an option in my > environment. > > > > So all the moving parts together, it appears that having AD groups > > with a different name than the IPA groups in conjunction with the > > default_domain_suffix setting breaks things right now in 1.12. > > Appears since I renamed the ad group to match then the rule without a > > domain suffix will get matched now > > Hello Andy, > > I'm sorry for the constant delays, but I was busy with some trust-related > fixes > lately. > > Did you have a chance to confirm that just swapping sssd /on the client/ > while keeping the same version on the server fixes the issue for you? > > Pavel (CC), can you help me out here, please? I have the setup ready on my > machine, so tomorrow we can take a look and experiment (I can give you > access to my environment via tmate maybe..), but I wasn't able to reproduce > the issue locally yet. It's fine I understand the backlog. I was not able to backrev the sssd due to dependency issues. I tried downgrading all the dependencies and got in a loop and stopped trying. Are there any tricks you can think of to downgrade the sssd cleanly? -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> On Mon, Sep 21, 2015 at 07:39:01PM +0000, Andy Thompson wrote: > > > -Original Message- > > > From: Jakub Hrozek [mailto:jhro...@redhat.com] > > > Sent: Monday, September 21, 2015 3:29 PM > > > To: Andy Thompson <andy.thomp...@e-tcc.com> > > > Cc: freeipa-users@redhat.com; pbrez...@redhat.com > > > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > > > > > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote: > > > > > > > > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > > > > > > I've narrowed it down a bit doing some testing. The sudo > > > > > > rules work when > > > > > I remove the user group restriction from them. My sudo rules > > > > > all have my ad groups in the rule > > > > > > > > > > > > Rule name: ad_linux_admins > > > > > > Enabled: TRUE > > > > > > Host category: all > > > > > > Command category: all > > > > > > RunAs User category: all > > > > > > RunAs Group category: all > > > > > > User Groups: ad_linux_admins <- if I remove this then the > > > > > > rule gets > > > > > applied > > > > > > > > > > Nice catch. Is the group visible after you login and run id? > > > > > > > > > > What is the exact IPA server version? > > > > > > > > Ok I also figured out if I rename my AD groups to match my IPA > > > > groups then > > > the sudo rules are applied. > > > > > > > > I tested a couple things though, if I put a rule in the local > > > > sudoers file on a server running sssd 1.11 > > > > > > > > %@ "sudo commands" > > > > > > > > That rule was not applied. If I remove the then the > > > > rule got > > > applied. > > > > > > > > On a server running sssd 1.12 that rule works, but does not work > > > > if I > > > remove the . And none of the IPA sudo rules work. So > > > something changed with the domain suffix between versions it would > > > appear. > > > > > > > > They key to making the IPA sudo rules work in 1.12 is to remove > > > > the > > > default_domain_suffix setting in the sssd.conf, but that's not an > > > option in my environment. > > > > > > > > So all the moving parts together, it appears that having AD groups > > > > with a different name than the IPA groups in conjunction with the > > > > default_domain_suffix setting breaks things right now in 1.12. > > > > Appears since I renamed the ad group to match then the rule > > > > without a domain suffix will get matched now > > > > > > Hello Andy, > > > > > > I'm sorry for the constant delays, but I was busy with some > > > trust-related fixes lately. > > > > > > Did you have a chance to confirm that just swapping sssd /on the > > > client/ while keeping the same version on the server fixes the issue for > you? > > > > > > Pavel (CC), can you help me out here, please? I have the setup ready > > > on my machine, so tomorrow we can take a look and experiment (I can > > > give you access to my environment via tmate maybe..), but I wasn't > > > able to reproduce the issue locally yet. > > > > It's fine I understand the backlog. > > > > I was not able to backrev the sssd due to dependency issues. I tried > downgrading all the dependencies and got in a loop and stopped trying. Are > there any tricks you can think of to downgrade the sssd cleanly? > > > > -andy > > > > What failures are you getting? I normally just download all \*sss\* packages > and then downgrade with rpm -U --oldpackage. I'm just trying to use yum. If I yum downgrade sssd I get a ton of deps. If include all the deps it lists yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python python-sssdconfig I get multilib errors with libsss_idmap. Looks like my local repo doesn't have libsss_idmap 1.11 available. Let me look into that and see what repo it sits in and see if I can figure out why it's not pulling in. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> > On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote: > > > > -Original Message- > > > > From: Jakub Hrozek [mailto:jhro...@redhat.com] > > > > Sent: Monday, September 21, 2015 3:29 PM > > > > To: Andy Thompson <andy.thomp...@e-tcc.com> > > > > Cc: freeipa-users@redhat.com; pbrez...@redhat.com > > > > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > > > > > > > On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote: > > > > > > > > > > > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > > > > > > > I've narrowed it down a bit doing some testing. The sudo > > > > > > > rules work when > > > > > > I remove the user group restriction from them. My sudo rules > > > > > > all have my ad groups in the rule > > > > > > > > > > > > > > Rule name: ad_linux_admins > > > > > > > Enabled: TRUE > > > > > > > Host category: all > > > > > > > Command category: all > > > > > > > RunAs User category: all > > > > > > > RunAs Group category: all > > > > > > > User Groups: ad_linux_admins <- if I remove this then the > > > > > > > rule gets > > > > > > applied > > > > > > > > > > > > Nice catch. Is the group visible after you login and run id? > > > > > > > > > > > > What is the exact IPA server version? > > > > > > > > > > Ok I also figured out if I rename my AD groups to match my IPA > > > > > groups then > > > > the sudo rules are applied. > > > > > > > > > > I tested a couple things though, if I put a rule in the local > > > > > sudoers file on a server running sssd 1.11 > > > > > > > > > > %@ "sudo commands" > > > > > > > > > > That rule was not applied. If I remove the then > > > > > the rule got > > > > applied. > > > > > > > > > > On a server running sssd 1.12 that rule works, but does not work > > > > > if I > > > > remove the . And none of the IPA sudo rules work. So > > > > something changed with the domain suffix between versions it would > > > > appear. > > > > > > > > > > They key to making the IPA sudo rules work in 1.12 is to remove > > > > > the > > > > default_domain_suffix setting in the sssd.conf, but that's not an > > > > option in my environment. > > > > > > > > > > So all the moving parts together, it appears that having AD > > > > > groups with a different name than the IPA groups in conjunction > > > > > with the default_domain_suffix setting breaks things right now in > 1.12. > > > > > Appears since I renamed the ad group to match then the rule > > > > > without a domain suffix will get matched now > > > > > > > > Hello Andy, > > > > > > > > I'm sorry for the constant delays, but I was busy with some > > > > trust-related fixes lately. > > > > > > > > Did you have a chance to confirm that just swapping sssd /on the > > > > client/ while keeping the same version on the server fixes the > > > > issue for > > you? > > > > > > > > Pavel (CC), can you help me out here, please? I have the setup > > > > ready on my machine, so tomorrow we can take a look and experiment > > > > (I can give you access to my environment via tmate maybe..), but I > > > > wasn't able to reproduce the issue locally yet. > > > > > > It's fine I understand the backlog. > > > > > > I was not able to backrev the sssd due to dependency issues. I > > > tried > > downgrading all the dependencies and got in a loop and stopped trying. > > Are there any tricks you can think of to downgrade the sssd cleanly? > > > > > > -andy > > > > > > > What failures are you getting? I normally just download all \*sss\* > > packages and then downgrade with rpm -U --oldpackage. > > > I'm just trying to use yum. If I yum downgrade sssd I get a ton of deps. If > include all the deps it lists > > yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> -Original Message- > From: Jakub Hrozek [mailto:jhro...@redhat.com] > Sent: Friday, September 18, 2015 4:42 AM > To: Andy Thompson <andy.thomp...@e-tcc.com> > Cc: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote: > > I've narrowed it down a bit doing some testing. The sudo rules work when > I remove the user group restriction from them. My sudo rules all have my ad > groups in the rule > > > > Rule name: ad_linux_admins > > Enabled: TRUE > > Host category: all > > Command category: all > > RunAs User category: all > > RunAs Group category: all > > User Groups: ad_linux_admins <- if I remove this then the rule gets > applied > > Nice catch. Is the group visible after you login and run id? Ya the groups show up for the users using id [athompson@mhbenp.local@mdhixuatsmtp01 ~]$ id uid=1506401106(athompson@mhbenp.local) gid=1506401106(athompson@mhbenp.local) groups=1506401106(athompson@mhbenp.local),124910(ad_linux_admins),1506400512(domain admins@mhbenp.local),1506400513(domain users@mhbenp.local),1506401124(admin vpn users@mhbenp.local),1506401239(linux admins@mhbenp.local) > > What is the exact IPA server version? Installed Packages ipa-server.x86_64 4.1.0-18.el7_1.4 thanks -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
I've narrowed it down a bit doing some testing. The sudo rules work when I remove the user group restriction from them. My sudo rules all have my ad groups in the rule Rule name: ad_linux_admins Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all User Groups: ad_linux_admins <- if I remove this then the rule gets applied Sudo Option: !authenticate -andy > -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Jakub Hrozek > Sent: Tuesday, September 15, 2015 8:37 AM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > Sorry for not replying sooner, many of us were mostly offline last week. > > I'll try to reproduce locally.. > > On Tue, Sep 15, 2015 at 12:24:45PM +, Andy Thompson wrote: > > I just updated several machines to RHEL 6.7 and seem to have broken my > sudo rules. I've tracked the problem down to having > > > > Default_domain_suffix = ad.domain > > > > In the sssd.conf. If I remove that I can login using the fqn from AD and > sudo rules are applied as configured. However I don't want to force my users > to change to using their fqn to login, and due to having db2 in the > environment our usernames are limited to 8 characters so we cannot use the > fqn regardless. > > > > I tested adding a local sudo rule for %ad_domain_group@ipa.domain and it > worked, but any IPA rules are not working. A rule in the sudoers would not > work unless it was a fqn either which I expected with the default domain > suffix set. > > > > Update installed sssd-1.12.4-47.el6.x86_64. Redhat wants me to test > downgrading my sssd, which I'm not entirely opposed to in order to get > things working, but there are some fixes in this release I kinda want to keep. > > > > -andy > > > > > > > > *** This communication may contain privileged and/or confidential > information. It is intended solely for the use of the addressee. If you are > not > the intended recipient, you are strictly prohibited from disclosing, copying, > distributing or using any of this information. If you received this > communication in error, please contact the sender immediately and destroy > the material in its entirety, whether electronic or hard copy. *** > > > > > > -- > > 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 > > > > > > *** This communication may contain privileged and/or confidential > information. It is intended solely for the use of the addressee. If you are > not > the intended recipient, you are strictly prohibited from disclosing, copying, > distributing or using any of this information. If you received this > communication in error, please contact the sender immediately and destroy > the material in its entirety, whether electronic or hard copy. *** > > > > > > -- > > 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
[Freeipa-users] rhel 6.7 upgrade - sssd/sudo
I just updated several machines to RHEL 6.7 and seem to have broken my sudo rules. I've tracked the problem down to having Default_domain_suffix = ad.domain In the sssd.conf. If I remove that I can login using the fqn from AD and sudo rules are applied as configured. However I don't want to force my users to change to using their fqn to login, and due to having db2 in the environment our usernames are limited to 8 characters so we cannot use the fqn regardless. I tested adding a local sudo rule for %ad_domain_group@ipa.domain and it worked, but any IPA rules are not working. A rule in the sudoers would not work unless it was a fqn either which I expected with the default domain suffix set. Update installed sssd-1.12.4-47.el6.x86_64. Redhat wants me to test downgrading my sssd, which I'm not entirely opposed to in order to get things working, but there are some fixes in this release I kinda want to keep. -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- 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 *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] rhel 6.7 upgrade - sssd/sudo
Ok I've got a strange one going on. I just updated several machines to RHEL 6.7 and seem to have broken my sudo rules. I've tracked the problem down to having Default_domain_suffix = ad.domain In the sssd.conf. If I remove that I can login using the fqn from AD and sudo rules are applied as configured. However I don't want to force my users to change to using their fqn to login, and due to having db2 in the environment our usernames are limited to 8 characters so we cannot use the fqn regardless. I testing adding a local sudo rule for %ad_domain_group@ipa.domain and it worked, but any IPA rules are not working. Update installed sssd-1.12.4-47.el6.x86_64 -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] nsslapd-maxbersize and cachememsize
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Andy Thompson Sent: Monday, July 6, 2015 2:28 PM To: Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] nsslapd-maxbersize and cachememsize -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Rich Megginson Sent: Monday, July 6, 2015 2:05 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] nsslapd-maxbersize and cachememsize On 07/06/2015 11:49 AM, Andy Thompson wrote: I've got a couple warnings in different IPA installs that I'm not sure how to find what values I should increase each config setting to. In one install I'm seeing the following [03/Jul/2015:22:03:02 -0400] connection - conn=16143 fd=122 Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. This ended up being a security scanner on the network causing the problem and nothing related to system functionality in any way. Second installation I'm seeing this on startup WARNING: changelog: entry cache size 858992B is less than db size 2293760B; We recommend to increase the entry cache size nsslapd- cachememsize. How can I determine what to increase each config setting to? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html-single/Configuration_and_Command-Line_Tool_Reference/index.html#cnconfig-nsslapd_maxbersize_Maximum_Message_Size -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] nsslapd-maxbersize and cachememsize
I've got a couple warnings in different IPA installs that I'm not sure how to find what values I should increase each config setting to. In one install I'm seeing the following [03/Jul/2015:22:03:02 -0400] connection - conn=16143 fd=122 Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. Second installation I'm seeing this on startup WARNING: changelog: entry cache size 858992B is less than db size 2293760B; We recommend to increase the entry cache size nsslapd-cachememsize. How can I determine what to increase each config setting to? Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] nsslapd-maxbersize and cachememsize
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Rich Megginson Sent: Monday, July 6, 2015 2:05 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] nsslapd-maxbersize and cachememsize On 07/06/2015 11:49 AM, Andy Thompson wrote: I've got a couple warnings in different IPA installs that I'm not sure how to find what values I should increase each config setting to. In one install I'm seeing the following [03/Jul/2015:22:03:02 -0400] connection - conn=16143 fd=122 Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. Second installation I'm seeing this on startup WARNING: changelog: entry cache size 858992B is less than db size 2293760B; We recommend to increase the entry cache size nsslapd- cachememsize. How can I determine what to increase each config setting to? What version of 389? rpm -q 389-ds-base Both are running ipa-server-4.1.0-18.el7_1.3.x86_64 389-ds-base-1.3.3.1-16.el7_1.x86_64 -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] username case sensitivity
On Wed, Jul 01, 2015 at 10:12:54AM +0200, Jakub Hrozek wrote: On Tue, Jun 30, 2015 at 08:16:05PM +, Andy Thompson wrote: On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is they ? I guess not SSSD but grabbing the data directly from LDAP? The match clauses in the sshd config were set to use lower case names. It is using sssd, just a regular ipa client installation. If I logged in using USERName insetad of username, the match clause did not work. -andy Do we have any follow up on this thread? Have we closed the loop and filed a ticket. I had couple complains of the similar matter during Red Hat Summit. I seems that this is one of the emerging issues for the trust environments. I wonder if it's still an issue with 1.12.x and the Kerberos plugin Sumit wrote. Do we have a way to track these requests? Andy, if you have some test machines, could you give 6.7 a try? The usernames from AD are still not case sensitive on 6.7 so a Match User Testuser Stanza in the ssh config is not matched if they login as testuser but does match if they login with Testuser Thanks for the reply. Then I guess sshd doesn't canonicalize the username with getpwnam(). But I admit I don't know exactly what sshd does, so I hope other developers would chime in here.. iirc sshd does call getpwnam() with the name given at the login prompt to determine if the user exists at all and its home-directory, shell, UID and GID which is needed later on. But it does not expect that the name gets canonicalized and continues to use the name given at the login prompt. I wonder if it would be possible to use group names in the Match clause in your setup? Since sshd must call getgroups() and getgrgid() to get this information here the lower-case group name returned by SSSD should work. Yes since the groups are retrievable with the new sssd without requiring the user to login any longer, that will work in my use case now. The only reason I ran into the case issue what that I can't use groups on 1.11.x since groups aren't available until a first login. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] disable unwanted kerberos encryption types
We have requirements to only allow AES encryption. I'm trying to understand what is the default and where everything comes in to play, the user tickets are AES when obtained using kinit, but the system keytab shows des3 and arcfour in addition to AES. So my questions are What is enabled/supported by default? How can des3 and arcfour encryption types be disabled for Kerberos? ? I've seen references to krbDefaultEncSaltTypes but cannot seem to find that in the directory anywhere. Are there any implications to doing this? Running RHEL 6.6 clients against 7.1 servers supporting local and trusted AD users. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] trusted user groups
-Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Monday, May 18, 2015 10:33 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (18/05/15 13:55), Andy Thompson wrote: -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I'm glad it works for you. I just can't roll them in production yet :/ I see. You have any insight into when 6.7 will be released? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] trusted user groups
-Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I just can't roll them in production yet :/ Thanks -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] username case sensitivity
-Original Message- From: Jakub Hrozek [mailto:jhro...@redhat.com] Sent: Monday, May 18, 2015 4:07 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Sun, May 17, 2015 at 10:26:45PM +, Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Sunday, May 17, 2015 5:23 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is they ? I guess not SSSD but grabbing the data directly from LDAP? The match clauses in the sshd config were set to use lower case names. It is using sssd, just a regular ipa client installation. If I logged in using USERName insetad of username, the match clause did not work. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] username case sensitivity
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Sunday, May 17, 2015 5:23 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] username case sensitivity
Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] trusted user groups
I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. Is there a chance that information will be dropped again at any point going forward? The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? Running sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.x86_64 on RHEL6x clients against a RHEL7 4.1 ipa server thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] trusted user groups
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Thanks much -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jan Pazdziora Sent: Monday, May 11, 2015 8:14 AM To: Alexander Bokovoy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, May 08, 2015 at 05:21:09PM +0300, Alexander Bokovoy wrote: On Fri, 08 May 2015, Andy Thompson wrote: On Fri, 08 May 2015, Andy Thompson wrote: I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ In any case, it is mostly a question of correct routing tables and DNS name resolution. Is there anything we can add to the tool on our side to catch the errors earlier and/or make the error messages less scary and more descriptive? Possibly error out and stop the setup entirely if DNS can't be resolved... make it a pre setup check and halt. Currently it allows the install to continue, albeit saying what happened. I just didn't pay close enough attention the first time around to see that it failed that step... I think I started it, went to another screen and came back and noted it was completed and moved forward. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
-Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 10:21 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 9:40 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 8:17 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr u st Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). Well things got ugly. I enabled debug and pointed in the right direction, smb failed to start. Came down to the cifs service was not added when I did the adtrust-install. I tried adding it and it complained that it could not find the A record for the host even though it was there. Thinking something was hung up in resolver cache possibly I restarted the ipa service and it failed completely. Ipactl start fails starting smb because of the missing service and everything fails from there. Is there any way to recover from this mess I just made? :) I assume you have IPA 4.x, i.e. systemd-based environment. Yes, sorry forgot to include that. 1. Start manually dirsrv@INSTANCE-NAME.service 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. Note that you SHOULD NOT replace $FOO variables below, they should be as specified in the resulting file. For ipa-ldap-updater use see its manual page and my blog: https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-upda ter/ # cat END 88-disable-adtrust-extid.update dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService END # ipa-ldap-updater -l ./88-disable-adtrust-extid.update 3. Restart IPA 4. Re-run ipa-adtrust-install and look at the output, including what it appends to /var/log/ipaserver-install.log. Beautiful, that much is running again, thanks for those pointers. And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ So back to the original issue that was in the end because smb wasn't started most likely. I'm still not sure how this will all respond in a multi homed environment like this if the IPA server cannot communicate with all of the interfaces on the DC. Will that cause an issue with the trust or is there anything I need to take into consideration with this? There are few things to consider: 1. IPA master uses DNS SRV records to discover whom to talk to on AD side. Received name from the SRV record is them used by IPA master to connect to the AD DC. 2. AD DCs use DNS SRV records to discover which IPA master to respond to when verifying trust. Received name from the SRV record is then used by AD DC to connect to the IPA master. 3. While right now trust is established using password-based authentication between IPA and AD DCs, actual resolution of identities when trust is in use requires working Kerberos authentication. This might give you a headache in multi-homed environments if the IP returned when resolving AD DC or IPA master would be unreachable. In any case
Re: [Freeipa-users] multi homed environment
-Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 9:40 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 8:17 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr u st Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). Well things got ugly. I enabled debug and pointed in the right direction, smb failed to start. Came down to the cifs service was not added when I did the adtrust-install. I tried adding it and it complained that it could not find the A record for the host even though it was there. Thinking something was hung up in resolver cache possibly I restarted the ipa service and it failed completely. Ipactl start fails starting smb because of the missing service and everything fails from there. Is there any way to recover from this mess I just made? :) I assume you have IPA 4.x, i.e. systemd-based environment. Yes, sorry forgot to include that. 1. Start manually dirsrv@INSTANCE-NAME.service 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. Note that you SHOULD NOT replace $FOO variables below, they should be as specified in the resulting file. For ipa-ldap-updater use see its manual page and my blog: https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ # cat END 88-disable-adtrust-extid.update dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService END # ipa-ldap-updater -l ./88-disable-adtrust-extid.update 3. Restart IPA 4. Re-run ipa-adtrust-install and look at the output, including what it appends to /var/log/ipaserver-install.log. Beautiful, that much is running again, thanks for those pointers. And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ So back to the original issue that was in the end because smb wasn't started most likely. I'm still not sure how this will all respond in a multi homed environment like this if the IPA server cannot communicate with all of the interfaces on the DC. Will that cause an issue with the trust or is there anything I need to take into consideration with this? Thanks much -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
-Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 8:17 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tru st Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). Well things got ugly. I enabled debug and pointed in the right direction, smb failed to start. Came down to the cifs service was not added when I did the adtrust-install. I tried adding it and it complained that it could not find the A record for the host even though it was there. Thinking something was hung up in resolver cache possibly I restarted the ipa service and it failed completely. Ipactl start fails starting smb because of the missing service and everything fails from there. Is there any way to recover from this mess I just made? :) thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] multi homed environment
I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] 2fa with trusted AD users
Is this possible or do they have to be local IPA accounts? Looking at options for setting up freeradius with IPA on the backend and utilizing OTP, I've got a test case setup and working for local accounts but a lot of our users are trusted accounts. From what I can tell it is not possible currently but I saw a reference along the line somewhere about external users. Can't really find much info otherwise. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
You got a first replica where you failed to delete the entry. You got a second replica where you succeeded to delete the entry. On first replica you can see messages like: [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 On the second replica you can see messages like: [29/Apr/2015:09:35:40 -0400] NSMMReplicationPlugin - agmt=cn=meTomdhixnpipa01.domain.com (mdhixnpipa01:389): Consumer failed to replay change (uniqueid 7e1a1f87-e82611e4-99f1b343-f0abc1a8, CSN 5540deb800030003): Operations error (1). Will retry later. On the first replica, you had difficulties to retrieve the entry and finally had to remove 'nsuniqueid' from the filter to retrieve this entry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb80003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f82-e82611e4-99f1b343-f0abc1a8 ... On the second replica you can the entry: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb800030003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8 Note that the entry retrieved on the first replica has nsuniqueid=7e1a1f82.. while the entry retrieved on the second replica has nsuniqueid=7e1a1f87 ... It differs '2' instead of '7'. So this is not the same entry (from replication point of view). The error reported in the first replica was about Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87... The error reported in the second replica was also about Consumer failed to replay change (uniqueid 7e1a1f87... So I think the entry you dumped on the first replica is not (should not be) the one we are looking for. It appears that f82 is the user object and f87 is the group object. So you are right, I don't think f82 is what we were looking for, it just happened to have the username in it when I grepped without filtering the uniqueid. I'm not sure why it was having problems with the user group object, but I don't have individual group objects showing up for any local accounts I've created. All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box yesterday and the error has not shown since. So I'm not sure if it was because of the minor upgrade or cycling the daemon. Is there any way to find the root cause of this? And is it normal that individual group objects are not created for users? I thought I remembered reading somewhere that they were derived and not static entries? The few accounts I have on there were created in the web interface, most of my users are all trust users. Although it could be two entries having the same DN but that was deleted, added and then deleted again. The difficulty is to retrieve it (on the first replica) as we cannot specify its 'nsuniqueid' to retrieve it. May be you can retrieve it with its ((objectclass=nstombstone)(ipauniqueid=94dc1638-e826-11e4-878a- 005056a92af3)) thanks thierry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: modifyTimestamp;adcsn- 5540be0c000200040002;vucsn-5540be0c000200040002: 20150429111607Z nscpentrywsi: modifiersName;adcsn-5540be0c000200040001;vucsn- 5540be0c000200040001: uid=admin,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: nsAccountLock;adcsn-5540be0c00020004;vucsn- 5540be0c00020004: TRUE nscpentrywsi: krbLastSuccessfulAuth;adcsn- 5537c9b20003;vucsn-5537c9b20003: 20150422161526Z nscpentrywsi: memberOf;adcsn-5537c2f500040003;vucsn- 5537c2f500040003: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: memberOf;vucsn-5537c2f500040003: ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=mhbenp,dc=lin nscpentrywsi: ipaNTSecurityIdentifier;adcsn- 5537a1b1000300040001;vucsn-5537a1b1000300040001: S-1-5-21-1257946092- 587846975-4124201916-1003 nscpentrywsi: passwordGraceUserTime;adcsn- 553692040004;vucsn-553692040004: 0 nscpentrywsi: krbPasswordExpiration;adcsn- 5536920200040005;vucsn-5536920200040005: 20150720180532Z nscpentrywsi: userPassword;adcsn-5536920200040004;vucsn- 5536920200040004:
Re: [Freeipa-users] deleting ipa user
It appears that f82 is the user object and f87 is the group object. So you are right, I don't think f82 is what we were looking for, it just happened to have the username in it when I grepped without filtering the uniqueid. I'm not sure why it was having problems with the user group object, but I don't have individual group objects showing up for any local accounts I've created. You are right. I think the private group of a user is/should be deleted at the same time when you delete a user. Is it normal that private groups do not show up in the user group listing or with ipa group-find commands? I thought I remembered seeing them on a freeipa 3 installation but I've checked a couple 4 installs and they don't show up. I just had a random issue a little bit ago with another account when I checked the user groups in the web interface it popped with an unknown error dialog. I have not been able to reproduce it again and don't see anything in the error logs or access log which would indicate any problems. All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box yesterday and the error has not shown since. So I'm not sure if it was because of the minor upgrade or cycling the daemon. The logs gave a lot of information but without a test case it could be difficult to identify the RC. Now as I mentioned I hit (with a non systematic test case) an other bug when deleting a user. It was impossible to remove the entry/group. In this bug I tested on standalone instance but on replicated topology I wonder if it could have the same symptom. I've not been able to reproduce the issue in my sandbox environment so I'm not sure. It is also replicated. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] allow trust users to login without domain
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, April 29, 2015 7:05 AM To: Andy Thompson; freeipa-users@redhat.com; Jakub Hrozek Subject: Re: [Freeipa-users] allow trust users to login without domain On 04/29/2015 12:57 PM, Andy Thompson wrote: In the environment I'm working on currently we have a single trusted AD domain and will never have any additional domain trusts in place. Is there a way to allow users to login without using @ad_domain in their username? We use DB2 in the environment and it's from the dark ages and doesn't like usernames with more than 8 chars :/ Thanks -andy This looks as a job for default_domain_suffix option. See man sssd.conf for details. Note that after this fix, IPA users would need to log in with fully qualified user name instead. CCing Jakub for reference. Perfect. I grepped the man page.. apparently didn't search for the right thing. Thanks much -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] allow trust users to login without domain
In the environment I'm working on currently we have a single trusted AD domain and will never have any additional domain trusts in place. Is there a way to allow users to login without using @ad_domain in their username? We use DB2 in the environment and it's from the dark ages and doesn't like usernames with more than 8 chars :/ Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] deleting ipa user
I'm trying to delete an IPA account and I get a generic operations error when trying to remove it. It looks like something is messed up with the group object. The user doesn't show up in the ipausers group and there also isn't a group object for the user in question. Here is the error from the attempt. [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry cn=ipausers,cn=groups,cn=accounts,dc=domain,dc=com: deleting member: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry ipaUniqueID=3897c894-e764-11e4-b05b-005056a92af3,cn=hbac,dc=domain,dc=com: deleting memberUser: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8,cn=username,cn=groups,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8,cn=username,cn=groups,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, April 29, 2015 8:31 AM To: Andy Thompson; freeipa-users@redhat.com; Ludwig Krispenz; Thierry Bordaz Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 01:26 PM, Andy Thompson wrote: I'm trying to delete an IPA account and I get a generic operations error when trying to remove it. It looks like something is messed up with the group object. The user doesn't show up in the ipausers group and there also isn't a group object for the user in question. Here is the error from the attempt. [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry cn=ipausers,cn=groups,cn=accounts,dc=domain,dc=com: deleting member: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=domain,dc= com: deleting memberUser: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed-entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) This is the first time I see this error. CCing Ludwig or Thierry to advise. Andy, please also include FreeIPA and 389-ds-base packages versions so that Thierry and Ludwig know what to look at. Here you go ipa-server-4.1.0-18.el7_1.3.x86_64 389-ds-base-1.3.3.1-15.el7_1.x86_64 Thanks much -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
This is looking like that on the replica where the errors are logged. The entry is a tombstone but can not be find with the nsuniqueid. If on that server you do ldapsearch -LLL -o ldif-wrap=no -Hldap://mdhixnpipa02 -x -D cn=directory manager -W -b dc=... ((objectclass=nstombstone)(ipaUniqueID=94dc1638-e826-11e4-878a- 005056a92af3)) This one returns nothing on either server. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 11:28 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 05:08 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:59 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 04:49 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:51 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user did you run the searches as directory manager ? Yep sure did that's weird, as directory manager you should be able to see the nscpentrywsi attribute, could you paste your full search request ? This returns the object ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa02 -x -D cn=directory manager -W -b dc=... ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0a bc1a8)) | grep -i objectClass This returns nothing ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa02 -x -D cn=directory manager -W -b dc=... ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0a bc1a8)) nscpentrywsi | grep -i objectClass and if you omit the grep ? still puzzled. Ah if I omit the grep on the second server I get dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: objectClass;vucsn-55364a4200050004: posixgroup nscpentrywsi: objectClass;vucsn-55364a4200050004: ipaobject nscpentrywsi: objectClass;vucsn-55364a4200050004: mepManagedEntry nscpentrywsi: objectClass;vucsn-55364a4200050004: top nscpentrywsi: objectClass;vucsn-5540deb800030003: nsTombstone nscpentrywsi: cn;vucsn-55364a4200050004;mdcsn-55364a4200050004: gfeigh nscpentrywsi: gidNumber;vucsn-55364a4200050004: 124903 nscpentrywsi: description;vucsn-55364a4200050004: User private group for username nscpentrywsi: mepManagedBy;vucsn-55364a4200050004: uid= username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: creatorsName;vucsn-55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: modifiersName;vucsn-55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: createTimestamp;vucsn-55364a4200050004: 20150421130152Z nscpentrywsi: modifyTimestamp;vucsn-55364a4200050004: 20150421130152Z nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8 nscpentrywsi: ipaUniqueID;vucsn-55364a4200050004: 94dc1638-e826-11e4-878a-005056a92af3 nscpentrywsi: parentid: 4 nscpentrywsi: entryid: 385 nscpentrywsi: nsParentUniqueId: 3763f193-e76411e4-99f1b343-f0abc1a8 nscpentrywsi: nstombstonecsn: 5540deb800030003 nscpentrywsi: nscpEntryDN: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: entryusn: 52327 thought I tried that before, apparently not. what is logged in the access log for these two searches? On 04/29/2015 04:34 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:28 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user can you do the followin search on both servers ? ldapsearch -LLL -o ldif-wrap=no -h xxx p xxx -x -D cn=directory manager - w xxx -b dc=xxx ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8)) nscpentrywsi | grep -i objectClass The server that I initially attempted the deletion on returns nothing. The second server (the one currently throwing the consumer failed replay error) returns this if I remove the nscpentrywsi attribute filter. If I leave the attribute filter I don't get anything objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top objectClass: nsTombstone -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: objectClass;vucsn-55364a4200050004: posixgroup nscpentrywsi: objectClass;vucsn-55364a4200050004: ipaobject nscpentrywsi: objectClass;vucsn-55364a4200050004: mepManagedEntry nscpentrywsi: objectClass;vucsn-55364a4200050004: top nscpentrywsi: objectClass;vucsn-5540deb800030003: nsTombstone nscpentrywsi: cn;vucsn-55364a4200050004;mdcsn-55364a4200050004: gfeigh nscpentrywsi: gidNumber;vucsn-55364a4200050004: 124903 nscpentrywsi: description;vucsn-55364a4200050004: User private group for username nscpentrywsi: mepManagedBy;vucsn-55364a4200050004: uid= username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: creatorsName;vucsn-55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: modifiersName;vucsn-55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: createTimestamp;vucsn-55364a4200050004: 20150421130152Z nscpentrywsi: modifyTimestamp;vucsn-55364a4200050004: 20150421130152Z nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8 nscpentrywsi: ipaUniqueID;vucsn-55364a4200050004: 94dc1638-e826-11e4-878a-005056a92af3 nscpentrywsi: parentid: 4 nscpentrywsi: entryid: 385 nscpentrywsi: nsParentUniqueId: 3763f193-e76411e4-99f1b343-f0abc1a8 nscpentrywsi: nstombstonecsn: 5540deb800030003 nscpentrywsi: nscpEntryDN: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: entryusn: 52327 thought I tried that before, apparently not. ok, so we have the entry on one server, the csn of the objectclass: tombstone is : objectClass;vucsn-5540deb800030003: nsTombstone , which matches the csn in the error log: Consumer failed to replay change (uniqueid 7e1a1f87-e82611e4-99f1b343- f0abc1a8, CSN 5540deb800030003): Operations error (1) so the state of the entry is as expected. Now we nend to find it on the other server. If the search for the filter with nstombstone does return nothing, could you try If I run ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa01 -x -D cn=directory manager -W -b dc=mhbenp,dc=lin ((objectclass=nstombstone)) I get below. If I add nsuniqueid to the filter it returns nothing on the primary server dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343-f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin memberOf: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin memberOf: ipaUniqueID=3897c894-e764-11e4-b05b-005056a92af3,cn=hbac,dc=mhbenp,dc=lin ipaNTSecurityIdentifier: S-1-5-21-1257946092-587846975-4124201916-1003 krbLastSuccessfulAuth: 20150421180533Z krbPasswordExpiration: 20150720180532Z userPassword:: e1NIQTUxMn1wekx2TytqSG9YQWkwL1RMWitXcE44dmFRRnFEWUJ3U3lrMTJab2ErNUdwakdWTVBnSzlJK0txdWF2b0pXdjZKbVZuZjdWb2txbG04NXpiWVhqTXQxUT09 krbExtraData:: AAJskTZVa2FkbWluZEBNSEJFTlAuTElOAA== krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBA6MDAgEBpIIBhDCCAYAwaKAbMBmgAwIBAKESBBBNSEJFTlAuTElOZ2ZlaWdooUkwR6ADAgESoUAEPiAA10A0LqF2hLTC5EP9ArjKyMvDEuNh7SFNR7uvAba4+sh8WRRVbT7DMByrlPvn1A 0miart7lTDnRh89BAbMFigGzAZoAMCAQChEgQQTUhCRU5QLkxJTmdmZWlnaKE5MDegAwIBEaEwBC4QAAc6BbDvPFsSAeCRjrt2yDkm0fiQWTt++y/lbFKDbSkZYSJpFnzSRaaIWW0AMGCgGzAZoAMCAQChEgQQTUhCRU5QLkxJTmdmZWlnaKFBMD +gAwIBEKE4BDYYACTz15wnIUghoNOEkvYZJUbcrXhAyFQsW4OpxTCzxInn+33pOsEXPlsdsYfc6uJeVl2bN/IwWKAbMBmgAwIBAKESBBBNSEJFTlAuTElOZ2ZlaWdooTkwN6ADAgEXoTAELhAAE9mQlmMsVmCvtRwKXdSf9b7CFCi4qZjwMj1cTwzD1FH6/IbmDSvRMUVw8wE= krbLoginFailedCount: 0 krbTicketFlags: 128 krbLastPwdChange: 20150421180532Z krbLastFailedAuth: 20150421180457Z mepManagedEntry: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin displayName: user name cn: User Name objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry objectClass: ipantuserattrs objectClass: nsTombstone loginShell: /bin/bash initials: GF gecos: User Name homeDirectory: /home/username uid: username mail: usern...@mhbenp.lin krbPrincipalName: usern...@mhbenp.lin givenName: User sn: name ipaUniqueID: 94d31f06-e826-11e4-878a-005056a92af3 uidNumber: 124903 gidNumber: 124903 nsParentUniqueId: 3763f192-e76411e4-99f1b343-f0abc1a8 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
-Original Message- From: thierry bordaz [mailto:tbor...@redhat.com] Sent: Wednesday, April 29, 2015 1:07 PM To: Andy Thompson Cc: Ludwig Krispenz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 06:45 PM, Andy Thompson wrote: -Original Message- From: thierry bordaz [mailto:tbor...@redhat.com] Sent: Wednesday, April 29, 2015 12:28 PM To: Andy Thompson Cc: Ludwig Krispenz; Martin Kosek; freeipa- us...@redhat.com mailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 05:58 PM, Andy Thompson wrote: dn: nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: objectClass;vucsn- 55364a4200050004: posixgroup nscpentrywsi: objectClass;vucsn- 55364a4200050004: ipaobject nscpentrywsi: objectClass;vucsn- 55364a4200050004: mepManagedEntry nscpentrywsi: objectClass;vucsn- 55364a4200050004: top nscpentrywsi: objectClass;vucsn- 5540deb800030003: nsTombstone nscpentrywsi: cn;vucsn- 55364a4200050004;mdcsn- 55364a4200050004: gfeigh nscpentrywsi: gidNumber;vucsn- 55364a4200050004: 124903 nscpentrywsi: description;vucsn- 55364a4200050004: User private group for username nscpentrywsi: mepManagedBy;vucsn- 55364a4200050004: uid= username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: creatorsName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: modifiersName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: createTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: modifyTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: nsUniqueId: 7e1a1f87- e82611e4- 99f1b343-f0abc1a8 nscpentrywsi: ipaUniqueID;vucsn- 55364a4200050004: 94dc1638-e826-11e4-878a- 005056a92af3 nscpentrywsi: parentid: 4 nscpentrywsi: entryid: 385 nscpentrywsi: nsParentUniqueId: 3763f193- e76411e4-99f1b343-f0abc1a8 nscpentrywsi: nstombstonecsn: 5540deb800030003 nscpentrywsi: nscpEntryDN: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: entryusn: 52327 thought I tried that before, apparently not. ok, so we have the entry on one server, the csn of the objectclass: tombstone is : objectClass;vucsn-5540deb800030003: nsTombstone , which matches the csn in the error log: Consumer failed to replay change (uniqueid 7e1a1f87- e82611e4-99f1b343- f0abc1a8, CSN 5540deb800030003): Operations error (1) so the state of the entry is as expected. Now we nend to find it on the other server. If the search for the filter
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 9:22 AM To: thierry bordaz Cc: Andy Thompson; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 03:14 PM, thierry bordaz wrote: On 04/29/2015 02:43 PM, Andy Thompson wrote: -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, April 29, 2015 8:31 AM To: Andy Thompson; freeipa-users@redhat.com mailto:freeipa-users@redhat.com ; Ludwig Krispenz; Thierry Bordaz Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 01:26 PM, Andy Thompson wrote: I'm trying to delete an IPA account and I get a generic operations error when trying to remove it. It looks like something is messed up with the group object. The user doesn't show up in the ipausers group and there also isn't a group object for the user in question. Here is the error from the attempt. [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry cn=ipausers,cn=groups,cn=accounts,dc=domain,dc=com: deleting member: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=domain,dc= com: deleting memberUser: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed- entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed- entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) This is the first time I see this error. CCing Ludwig or Thierry to advise. Andy, please also include FreeIPA and 389-ds-base packages versions so that Thierry and Ludwig know what to look at. Here you go ipa-server-4.1.0-18.el7_1.3.x86_64 389-ds-base-1.3.3.1-15.el7_1.x86_64 Thanks much -andy Hello, I wonder it is not a similar issue I hit https://fedorahosted.org/389/ticket/48165. What differs is '_update_all_per_mod' logs but could be a consequence of the same bug. I think what differs taht in the ticket there is an attempt to delete an existng entry, but in the log snippet provided it attempts to delete a tombstone entry (an entry which was already deleted). So the errors logged by DS seem to be ok, but why does IPA want to delete an already deleted user ? but mybe only the mep plugin finds a tombstone and tries to delete it. What was the command executed, is the result the same if repeated ? I attempted using the web interface initially and then tried using ipa user-del username to see if it gave any more detail. More info though, this is a replicated environment and I just tried deleting it on the replica server and it completed successfully so it appears I might have a replication issue going on? Hopefully I didn't mess something up doing that, should have checked the logs there first. I see this in the logs on the replica [29/Apr/2015:09:35:40 -0400] NSMMReplicationPlugin
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:51 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user did you run the searches as directory manager ? Yep sure did On 04/29/2015 04:34 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:28 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user can you do the followin search on both servers ? ldapsearch -LLL -o ldif-wrap=no -h xxx p xxx -x -D cn=directory manager - w xxx -b dc=xxx ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8)) nscpentrywsi | grep -i objectClass The server that I initially attempted the deletion on returns nothing. The second server (the one currently throwing the consumer failed replay error) returns this if I remove the nscpentrywsi attribute filter. If I leave the attribute filter I don't get anything objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top objectClass: nsTombstone -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:07 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 03:40 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 9:22 AM To: thierry bordaz Cc: Andy Thompson; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 03:14 PM, thierry bordaz wrote: On 04/29/2015 02:43 PM, Andy Thompson wrote: -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, April 29, 2015 8:31 AM To: Andy Thompson; freeipa-users@redhat.com mailto:freeipa-users@redhat.com ; Ludwig Krispenz; Thierry Bordaz Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 01:26 PM, Andy Thompson wrote: I'm trying to delete an IPA account and I get a generic operations error when trying to remove it. It looks like something is messed up with the group object. The user doesn't show up in the ipausers group and there also isn't a group object for the user in question. Here is the error from the attempt. [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry cn=ipausers,cn=groups,cn=accounts,dc=domain,dc=com: deleting member: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] referint-plugin - _update_all_per_mod: entry ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=domain,dc= com: deleting memberUser: uid=username,cn=users,cn=accounts,dc=domain,dc=com failed (16) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed- entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=group s,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 [29/Apr/2015:07:21:32 -0400] managed- entries-plugin - mep_del_post_op: failed to delete managed entry (cn=username,cn=groups,cn=accounts,dc=domain,dc=com) - error (1) This is the first time I see this error. CCing Ludwig or Thierry to advise. Andy, please also include FreeIPA and 389-ds-base packages versions so that Thierry and Ludwig know what to look at. Here you go ipa-server-4.1.0-18.el7_1.3.x86_64 389-ds-base-1.3.3.1-15.el7_1.x86_64 Thanks much -andy Hello, I wonder it is not a similar issue I hit https://fedorahosted.org/389/ticket/48165. What differs is '_update_all_per_mod' logs but could be a consequence of the same bug. I think what differs taht in the ticket there is an attempt to delete an existng entry, but in the log snippet provided it attempts to delete a tombstone entry (an entry which was already deleted). So the errors logged by DS seem to be ok, but why does IPA want to delete an already deleted user ? but mybe only the mep plugin finds a tombstone and tries to delete it. What was the command executed, is the result the same if repeated ? I attempted using the web interface initially and then tried using ipa user-del username to see if it gave any more detail. were both attempts at 2015:07:21:32 ? or do you have more errors in the error log ? I had errors from the other delete attempts
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:28 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user can you do the followin search on both servers ? ldapsearch -LLL -o ldif-wrap=no -h xxx p xxx -x -D cn=directory manager - w xxx -b dc=xxx ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8)) nscpentrywsi | grep -i objectClass The server that I initially attempted the deletion on returns nothing. The second server (the one currently throwing the consumer failed replay error) returns this if I remove the nscpentrywsi attribute filter. If I leave the attribute filter I don't get anything objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top objectClass: nsTombstone -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
-Original Message- From: thierry bordaz [mailto:tbor...@redhat.com] Sent: Wednesday, April 29, 2015 12:28 PM To: Andy Thompson Cc: Ludwig Krispenz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 05:58 PM, Andy Thompson wrote: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: objectClass;vucsn- 55364a4200050004: posixgroup nscpentrywsi: objectClass;vucsn- 55364a4200050004: ipaobject nscpentrywsi: objectClass;vucsn- 55364a4200050004: mepManagedEntry nscpentrywsi: objectClass;vucsn- 55364a4200050004: top nscpentrywsi: objectClass;vucsn- 5540deb800030003: nsTombstone nscpentrywsi: cn;vucsn-55364a4200050004;mdcsn- 55364a4200050004: gfeigh nscpentrywsi: gidNumber;vucsn- 55364a4200050004: 124903 nscpentrywsi: description;vucsn- 55364a4200050004: User private group for username nscpentrywsi: mepManagedBy;vucsn- 55364a4200050004: uid= username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: creatorsName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: modifiersName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: createTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: modifyTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4- 99f1b343-f0abc1a8 nscpentrywsi: ipaUniqueID;vucsn- 55364a4200050004: 94dc1638-e826-11e4-878a-005056a92af3 nscpentrywsi: parentid: 4 nscpentrywsi: entryid: 385 nscpentrywsi: nsParentUniqueId: 3763f193- e76411e4-99f1b343-f0abc1a8 nscpentrywsi: nstombstonecsn: 5540deb800030003 nscpentrywsi: nscpEntryDN: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: entryusn: 52327 thought I tried that before, apparently not. ok, so we have the entry on one server, the csn of the objectclass: tombstone is : objectClass;vucsn-5540deb800030003: nsTombstone , which matches the csn in the error log: Consumer failed to replay change (uniqueid 7e1a1f87- e82611e4-99f1b343- f0abc1a8, CSN 5540deb800030003): Operations error (1) so the state of the entry is as expected. Now we nend to find it on the other server. If the search for the filter with nstombstone does return nothing, could you try If I run ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa01 -x -D cn=directory manager -W -b dc=mhbenp,dc=lin ((objectclass=nstombstone)) I get below. If I add nsuniqueid to the filter it returns nothing on the primary server dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin memberOf: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin memberOf: ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=mhbenp,dc=lin ipaNTSecurityIdentifier: S-1-5-21-1257946092-587846975-4124201916- 1003 krbLastSuccessfulAuth: 20150421180533Z krbPasswordExpiration: 20150720180532Z userPassword:: e1NIQTUxMn1wekx2TytqSG9YQWkwL1RMWitXcE44dmFRRnFEWUJ3U3lrMTJ ab2ErNUdwakdWTVBnSzlJK0txdWF2b0pXdjZKbVZuZjdWb2txbG04NXpiWVh qTXQxUT09 krbExtraData:: AAJskTZVa2FkbWluZEBNSEJFTlAuTElOAA== krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBA6MDAgEBpIIBhDCCAYAwaKAbMBmgAwIB AKESBBBNSEJFTlAuTElOZ2ZlaWdooUkwR6ADAgESoUAEPiAA10A0LqF2hLTC5E P9ArjKyMvDEuNh7SFNR7uvAba4+sh8WRRVbT7DMByrlPvn1A 0miart7lTDnRh89BAbMFigGzAZoAMCAQChEgQQTUhCRU5QLkxJTmd mZWlnaKE5MDegAwIBEaEwBC4QAAc6BbDvPFsSAeCRjrt2yDkm0fiQWTt++y/l bFKDbSkZYSJpFnzSRaaIWW0AMGCgGzAZoAMCAQChEgQQTUhCRU5QLkxJT mdmZWlnaKFBMD +gAwIBEKE4BDYYACTz15wnIUghoNOEkvYZJUbcrXhAyFQsW4OpxTCz xInn+33pOsEXPlsdsYfc6uJeVl2bN/IwWKAbMBmgAwIBAKESBBBNSEJFTlAuTEl
Re: [Freeipa-users] deleting ipa user
-Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:59 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 04:49 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:51 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user did you run the searches as directory manager ? Yep sure did that's weird, as directory manager you should be able to see the nscpentrywsi attribute, could you paste your full search request ? This returns the object ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa02 -x -D cn=directory manager -W -b dc=... ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8)) | grep -i objectClass This returns nothing ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa02 -x -D cn=directory manager -W -b dc=... ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4-99f1b343-f0abc1a8)) nscpentrywsi | grep -i objectClass On 04/29/2015 04:34 PM, Andy Thompson wrote: -Original Message- From: Ludwig Krispenz [mailto:lkris...@redhat.com] Sent: Wednesday, April 29, 2015 10:28 AM To: Andy Thompson Cc: thierry bordaz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user can you do the followin search on both servers ? ldapsearch -LLL -o ldif-wrap=no -h xxx p xxx -x -D cn=directory manager - w xxx -b dc=xxx ((objectclass=nstombstone)(nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8)) nscpentrywsi | grep -i objectClass The server that I initially attempted the deletion on returns nothing. The second server (the one currently throwing the consumer failed replay error) returns this if I remove the nscpentrywsi attribute filter. If I leave the attribute filter I don't get anything objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top objectClass: nsTombstone -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] generic failure: GSSAPI Error: Unspecified GSS failure
I try to set the sudo password but I get a message : GSSAPI Error What's mean this kind of message ? ldappasswd -Y GSSAPI -S -h my_server uid=sudo,cn=sysaccounts,cn=etc,dc=my_domain,dc=com New password: Re-enter new password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) Your kerberos ticket has expired. You need to get a new ticket using kinit and then try using gssapi. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] passwordStorageScheme
-Original Message- From: Sankar Ramlingam [mailto:sraml...@redhat.com] Sent: Sunday, March 29, 2015 4:35 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] passwordStorageScheme On 03/28/2015 12:32 AM, Andy Thompson wrote: -Original Message- From: Sankar Ramlingam [mailto:sraml...@redhat.com] Sent: Friday, March 27, 2015 2:00 PM To: Andy Thompson Subject: Re: [Freeipa-users] passwordStorageScheme On 03/27/2015 11:17 PM, Andy Thompson wrote: Can you show me the output for this command? ldapsearch -LLL -x -p $PORT -h localhost -D cn=Directory Manager -w x -b cn=config |grep -i passwordStorageScheme Returns passwordStorageScheme: SSHA Also, can you paste me the content of pw.ldif file? and tell me what dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: SHA512 It looks like some whitespace characters in your ldif file. Can you recreate the ldif file with no special/whitespace characters? or can you run ldapmodify from command line and change the value directly? . I copied your ldif file content and it failed for me too. Then, I tried copying my ldif file and it was a success. Pasting the content here... dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: SHA512 EOF Thanks much for the assist. Haven't ever run into that before. Hi Andy, So, I understand it was a problem with the LDIF file. I hope the problem is solved now. Please confirm. Yes the problem is solved. Was just some extra spaces or something not visible to the eye that snuck in when I copied and pasted it from a document I've been compiling on all of my setup and testing. Thanks again -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] passwordStorageScheme
Relative newb here :) I'm doing some research trying to sort out the password storage scheme being used on the freeipa LDAP instance. From everything I can find it uses ssha but can be changed to ssha-512. But when I try to change that attribute on the cn=config object like referenced here https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management.html#Configuring_a_Global_Password_Policy_Using_the_Command_Line-Password_Policy_Attributes It comes back with wrong attribute type. I realize that doc points to the RHDS so it might be valid for the ipa ds? So I guess my question is what hash is used by freeipa to store password hashes and is it configurable? *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- 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
