Discussion:
[Freeipa-users] shadow netgroups with wrong domains - sudo problem
Bob Hinton
2017-03-17 06:50:34 UTC
Permalink
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 ?

Many thanks

Bob
--
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
Jakub Hrozek
2017-03-17 08:41:51 UTC
Permalink
Post by Bob Hinton
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..)
--
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
Bob Hinton
2017-03-17 10:40:52 UTC
Permalink
Post by Jakub Hrozek
Post by Bob Hinton
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.

Thanks

Bob
--
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
Lukas Slebodnik
2017-03-17 12:48:57 UTC
Permalink
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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
--
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
Bob Hinton
2017-03-17 13:52:17 UTC
Permalink
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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
objectClass: ipanisnetgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: ipaAssociation
objectClass: top
nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10
--
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
Lukas Slebodnik
2017-03-17 14:01:56 UTC
Permalink
Post by Bob Hinton
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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.
Post by Bob Hinton
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
Bob Hinton
2017-03-17 21:52:22 UTC
Permalink
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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.
Post by Bob Hinton
objectClass: ipanisnetgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: ipaAssociation
objectClass: top
nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10
LS
Hi Jakub,

I've tried using ldapsearch to retrieve this record but the results
don't include the nisDomainName field. Can you give me any pointers how
to access this attribute so I can edit it ?

Many thanks

Bob
--
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
Bob Hinton
2017-03-18 13:13:15 UTC
Permalink
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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.
Post by Bob Hinton
objectClass: ipanisnetgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: ipaAssociation
objectClass: top
nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10
LS
Hi Jakub,

Having looked into this in more detail and I think the route of the
problem is that the first master created was ipa001.mgmt.prod.local.lan
and therefore mgmt.prod.local.lan seems to have been taken as the
default domain for netgroups even though both the domain and realm were
set as local.lan. In the original configuration the first master was
ipa001.local.lan. It was eventually replaced with
ipa001.mgmt.prod.local.lan via replication but that original base level
seems to have stuck.

Can this base setting of mgmt.prod.local.lan somehow be changed to
local.lan so that newly created netgroups get this as their nisdomain ?

Thanks

Bob
--
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
Bob Hinton
2017-03-18 15:11:43 UTC
Permalink
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.

Many thanks

Bob Hinton
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Alexander Bokovoy
2017-03-18 17:03:49 UTC
Permalink
Post by Bob Hinton
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'.
--
/ 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
Bob Hinton
2017-03-18 17:28:03 UTC
Permalink
Post by Alexander Bokovoy
Post by Bob Hinton
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.

Many thanks

Bob
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Alexander Bokovoy
2017-03-18 19:09:20 UTC
Permalink
Post by Bob Hinton
Post by Alexander Bokovoy
Post by Bob Hinton
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.
--
/ 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
Bob Hinton
2017-03-18 21:49:20 UTC
Permalink
Post by Alexander Bokovoy
Post by Bob Hinton
Post by Alexander Bokovoy
Post by Bob Hinton
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.
-----
# 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
-----
# 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- |\
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.
-----
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
--
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
Jakub Hrozek
2017-03-20 08:29:26 UTC
Permalink
Post by Bob Hinton
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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 ?
Sorry, I'm not sure. I hope someone with better insight into the IPA
framework knows.
--
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
Bob Hinton
2017-03-20 08:35:33 UTC
Permalink
Post by Jakub Hrozek
Post by Bob Hinton
Post by Lukas Slebodnik
Post by Bob Hinton
Post by Jakub Hrozek
Post by Bob Hinton
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 ?
Sorry, I'm not sure. I hope someone with better insight into the IPA
framework knows.
Morning Jakub, I sent a related post "default nisdomain appears to be
derived from hostname of first master rather than set to domain or
realm" and Alexander Bukovoy explained how to fix this.

Many Thanks

Bob Hinton
--
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
Loading...