[Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm [SOLVED]

[Bob Hinton]

On 18/03/2017 19:09, Alexander Bokovoy wrote:
> On la, 18 maalis 2017, Bob Hinton wrote:
>> On 18/03/2017 17:03, Alexander Bokovoy wrote:
>>> On la, 18 maalis 2017, Bob Hinton wrote:
>>>> Hi,
>>>>
>>>> The first IPA master we built was ipa001.local.lan. We have since
>>>> created a number of subdomains of local.lan and have created a
>>>> number of
>>>> replicas. The current configuration has two clusters of IPA replicas -
>>>> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and
>>>> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan
>>>>
>>>> We've recently commenced migrating some of the existing systems to
>>>> a new
>>>> environment and for various reasons have started with a fresh master -
>>>> ipa001.mgmt.prod.local.lan.
>>>>
>>>> Quite a lot of sudo rules don't work in the new environment. As far
>>>> as I
>>>> can tell this is because the shadow netgroups have a nisdomain of
>>>> mgmt.prod.local.lan instead of local.lan.
>>>>
>>>> I would have thought that the nisdomain should be set to either the
>>>> domain or realm i.e. local.lan rather than seemingly taken from the
>>>> network portion of the first master mgmt.prod.local.lan. Is this
>>>> correct ?
>>>>
>>>> Is there a way to change the default nisdomain ? Rebuilding all the
>>>> new
>>>> IPA masters and migrating all the data again would be a lot of work.
>>> The code that handles 'ipa netgroup-add' defaults to IPA domain as
>>> default NIS domain name. You can change that by explicitly adding
>>> '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change
>>> it for existing netgroups by specifying --nisdomain option to 'ipa
>>> netgroup-mod'.
>>>
>> Hi Alexander,
>>
>> Thanks for the information. Unfortunately, it's the shadow netgroups
>> created for hostgroups that are the problem. These aren't visible so can
>> I modify them with "ipa netgroup-mod" ? Also the default NIS domain name
>> doesn't match the IPA domain on our system, which is why I'm wondering
>> if we've hit a bug. This is IPA version 4.4.0.
> Got you. No, this is not a bug, you can fix your setup by specifying a
> different nisDomainName in the NGP HGP template definition. This would
> change default nisDomainName for new netgroups. For existing ones you
> would need to go and change nisDomainName attribute manually.
>
> You can do both of these operations with ipa-ldap-updater tool.
>
> 1. Changing default nisDomainName in the NGP HGP template.
>
> First, check what
> nisDomainName value is in the template. Let's assume your domain suffix
> is dc=example,dc=com below. I'll replace it with $DOMAINDN in the output
> for brevity.
>
> -----
> # export DOMAINDN='dc=example,dc=com'
> # ldapsearch -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' '
> -f3` -b  "cn=NGP HGP Template,cn=Templates,cn=Managed
> Entries,cn=etc,$DOMAINDN"
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> # extended LDIF
> #
> # LDAPv3
> # base <cn=NGP HGP Template,cn=Templates,cn=Managed
> Entries,cn=etc,$DOMAINDN> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # NGP HGP Template, Templates, Managed Entries, etc, example.com
> dn: cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,$DOMAINDN
> objectClass: mepTemplateEntry
> objectClass: top
> cn: NGP HGP Template
> mepRDNAttr: cn
> mepStaticAttr: ipaUniqueId: autogenerate
> mepStaticAttr: objectclass: ipanisnetgroup
> mepStaticAttr: objectclass: ipaobject
> mepStaticAttr: nisDomainName: example.com
> mepMappedAttr: cn: $cn
> mepMappedAttr: memberHost: $dn
> mepMappedAttr: description: ipaNetgroup $cn
>
> # search result
> search: 3
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> -----
>
> You can see 'mepStaticAttr: nisDomainName: example.com' there. This is
> the attribute and the value we should replace.
>
> Now create an update file that replaces nisDomainName with a new one.
>
> -----
> # cat 80-change-nisdomainname.update dn: cn=NGP HGP
> Template,cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX
> replace:mepStaticAttr:nisDomainName: example.com::nisDomainName:
> newexample.com
> -----
>
> In the update file above $SUFFIX is one of variables recognized by
> ipa-ldap-updater tool. Read its man page for more details.
>
> Run the tool:
>
> -----
> # ipa-ldap-updater ./80-change-nisdomainname.update
> Update complete
> The ipa-ldap-updater command was successful
> -----
>
> Now you can use the same ldapsearch command to verify that nisDomainName
> was changed in the template definition.
>
> 2. Change nisDomainName in the MEP entries.
>
> Since NGP HGP template uses mepStaticAttr to define nisDomainName
> attribute in the MEP entries generated with the help of this template,
> you need to change individual entries now. To do so you can gather DNs
> of the entries and create an update file that changes all of them in one
> go:
>
> -----
> # ldapsearch -Q -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' '
> -f3` \
>             -b  cn=ng,cn=alt,$DOMAINDN \
>         
> '(&(nisDomainName=example.com)(objectclass=mepManagedEntry))'  -LL dn |\
>          grep dn: | cut -d: -f2- |\
>          xargs -n1 printf "dn: %s\nreplace:nisDomainName:
> example.com::newexample.com\n\n"
> -----
>
> The pipeline above looks through entries in cn=ng,cn=alt,$DOMAINDN that
> were generated by MEP plugin (objectclass=mepManagedEntry) and has
> nisDomainName set to example.com. For these entries their DNs printed
> out and their values used to construct two new lines per each output.
> This would generate output similar to what I have below:
>
> -----
> dn: cn=myhostgroup,cn=ng,cn=alt,dc=xs,dc=example,dc=com
> replace:nisDomainName: example.com::myexample.com
>
> -----
>
> If you redirect the output to a file named NN-some-name.update where NN
> is between 00 and 90 (this is not documented in the man page, sorry),
> then you can supply this file to ipa-ldap-updater similar how we did it
> in the step 1.
>
Hi Alexander,

Worked a treat. Sudo rules for all the affected hostgroups now works.

Many thanks.

Bob