On (17/03/17 13:52), Bob Hinton wrote: >On 17/03/2017 12:48, Lukas Slebodnik wrote: >> On (17/03/17 10:40), Bob Hinton wrote: >>> On 17/03/2017 08:41, Jakub Hrozek wrote: >>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>>> Morning, >>>>> >>>>> We have a collection of hosts within prod1.local.lan. However, the >>>>> domain section of the shadow netgroups for the hosts is >>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>>> hosts unless they specify all hosts - >>>>> >>>>> -sh-4.2$ getent netgroup oepp_hosts >>>>> oepp_hosts >>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> -sh-4.2$ hostname >>>>> oeppredis001.z4.prod1.local.lan >>>>> -sh-4.2$ nisdomainname >>>>> local.lan >>>>> -sh-4.2$ domainname >>>>> local.lan >>>>> >>>>> The VMs associated with these hosts have recently been migrated and >>>>> re-enrolled against a new IPA server. The originals all had netgroup >>>>> domains of local.lan so something must have gone wrong in the migration >>>>> process. Is there a way to correct the netgroup domains of these hosts, >>>>> or is the only option to run ipa-client-install --uninstall followed by >>>>> ipa-client-install to reattach them ? >>>> Did you remove the sssd cache after the migration? >>>> rm -f /var/lib/sss/db/*.ldb >>>> >>>> (please make sure the clients can reach the server or maybe mv the cache >>>> instead of rm so you can restore cached credentials if something goes >>>> wrong..) >>>> >>> Hi Jakub, >>> >>> I've now tried removing the sssd cache on one of the offending servers >>> and it's not made any difference. >>> >>> getent netgroup oepp_hosts >>> >>> when run from any host enrolled to the new IPA servers, including the >>> IPA masters themselves produces the results with "mgmt.prod" included >>> and the same thing run on any of the pre-migrated servers that are still >>> commissioned produces them without, so I assume that the netgroup domain >>> information is coming from the IPA masters rather than the local host. >>> >> Could you provide content of LDIF from IPA server? >> For this netgroup/hostgroup >> >> LS > >Hi Jakub, > >I extracted the following from the userRoot ldif produced by "ipa-backup >--data". > >It appears to have the incorrect domain set against nisDomainName. Could >this be changed with ldapmodify ? > >Thanks > >Bob > ># entry-id: 1485 >dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan >ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b >modifyTimestamp: 20170222163643Z >createTimestamp: 20170222163643Z >modifiersName: cn=Managed Entries,cn=plugins,cn=config >creatorsName: cn=Managed Entries,cn=plugins,cn=config >mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >description: ipaNetgroup oepp_hosts >memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >cn: oepp_hosts >nisDomainName: mgmt.prod.local.lan And value of this attribute is an explanation to your question why there is a different domain in netgroups.
>objectClass: ipanisnetgroup >objectClass: ipaobject >objectClass: mepManagedEntry >objectClass: ipaAssociation >objectClass: top >nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10 LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
