Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
JR Aquino wrote: Attached are both patches with one modification to 0001: -add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX' +add:schema-compat-container-group: 'ou=SUDOers, $SUFFIX' Please ack and push to master. ack, pushed to master On 12/15/10 8:16 PM, JR Aquinojr.aqu...@citrix.com wrote: Perfect! All tests check out clean! One final piece I think needs a quick one liner: From: http://www.gratisoft.us/sudo/sudoers.ldap.man.html --The sudoers configuration is contained in the ou=SUDOers LDAP container.-- Currently the plugin creates 'cn=sudoers' as opposed to 'ou=sudoers'. After that change I believe we've nailed it 100%! Thank you very much Nalin ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
Thanks! Testing now. On 12/15/10 2:49 PM, Nalin Dahyabhai na...@redhat.com wrote: On Wed, Dec 15, 2010 at 09:29:53PM +, JR Aquino wrote: Thank you very much Nalin, at first glance these patches appear to solve what we are after. However, it looks like the master has drifted a little and these don't apply correctly. Could I ask you to do a quick spot-check and verify that we can apply these against the current master? Looks fine from here. Attached are rebased versions, just in case. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
Perfect! All tests check out clean! One final piece I think needs a quick one liner: From: http://www.gratisoft.us/sudo/sudoers.ldap.man.html --The sudoers configuration is contained in the ou=SUDOers LDAP container.-- Currently the plugin creates 'cn=sudoers' as opposed to 'ou=sudoers'. After that change I believe we've nailed it 100%! Thank you very much Nalin ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
On 12/9/10 10:03 AM, Dmitri Pal d...@redhat.com wrote: Nalin Dahyabhai wrote: On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote: I guess the piece that is still missing then is: Instead of: sudoHost: hostname.com It should be: sudoHost: +production - which is the group assigned to the ipasudorule. The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in the rule is a hostgroup but not a netgroup, so I think it's doing the right thing by resolving the group down to its members' names. JR, Can we check that we are running with the same test data set? In the data set that Nalin uses the sudo rule points to a host group so according to the rules it gets expanded. Have you implemented a capability to add a netgroup to the the memberHost in the SUDO plugin? If you make a netgroup a member of the SUDO rule the compat plugin will do what you expect. Thanks Dmitri Dmitri, you were absolutely correct!!! Thank you for setting me straight. Changing the memberhost in the sudorole from a hostgroup to a netgroup solved the issue. It is representing correctly as +prod now! Observation: A ticket was created for me to design a 'Managed Entry' plugin which automatically mirrored netgroups out of hostgroups which are created. FreeIPA's implementation of sudo has thus far been separated between, an IPAsudo object, and a compat translated sudo object. Might it be a more lasting solution to have the compat and sudo plugin refer to the hostgroup object and allow for the Managed Entry and 'NIS Compat' pieces handle the sudo native translations? That way we have a stand alone ipa centric model that allows us to completely strip away the translation pieces when they are no longer necessary (when sudo supports sssd). Or would it make more sense to just modify the sudo plugin to allow for: a single host, a hostgroup, and a netgroup as options for the memberHost attr? Thoughts? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
JR Aquino wrote: On 12/9/10 10:03 AM, Dmitri Pal d...@redhat.com wrote: Nalin Dahyabhai wrote: On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote: I guess the piece that is still missing then is: Instead of: sudoHost: hostname.com It should be: sudoHost: +production - which is the group assigned to the ipasudorule. The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in the rule is a hostgroup but not a netgroup, so I think it's doing the right thing by resolving the group down to its members' names. JR, Can we check that we are running with the same test data set? In the data set that Nalin uses the sudo rule points to a host group so according to the rules it gets expanded. Have you implemented a capability to add a netgroup to the the memberHost in the SUDO plugin? If you make a netgroup a member of the SUDO rule the compat plugin will do what you expect. Thanks Dmitri Dmitri, you were absolutely correct!!! Thank you for setting me straight. Changing the memberhost in the sudorole from a hostgroup to a netgroup solved the issue. It is representing correctly as +prod now! Observation: A ticket was created for me to design a 'Managed Entry' plugin which automatically mirrored netgroups out of hostgroups which are created. FreeIPA's implementation of sudo has thus far been separated between, an IPAsudo object, and a compat translated sudo object. Might it be a more lasting solution to have the compat and sudo plugin refer to the hostgroup object and allow for the Managed Entry and 'NIS Compat' pieces handle the sudo native translations? That way we have a stand alone ipa centric model that allows us to completely strip away the translation pieces when they are no longer necessary (when sudo supports sssd). Or would it make more sense to just modify the sudo plugin to allow for: a single host, a hostgroup, and a netgroup as options for the memberHost attr? I think this is how it is designed right now. The migration to host groups will be slow and painful. I think that approach we planned covers all main use cases and provides enough flexibility for administrators transition from old models and concepts to the new ones. There will be need to the compatibility for older clients for the years to come. Thoughts? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
JR Aquino wrote: I think this is how it is designed right now. The migration to host groups will be slow and painful. I think that approach we planned covers all main use cases and provides enough flexibility for administrators transition from old models and concepts to the new ones. There will be need to the compatibility for older clients for the years to come. The design doc seems to disagree: http://freeipa.org/page/SUDO_Schema_Design objectclass: ipaSudoRule ... memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,... ... Just to review, so that I can make sure the patch is posted correctly: The current Sudo Compat Plugin functions as long as: An IPASudoRule can consist of: memberUser: Single_User|Group memberAllowCmd: Single_CMD|SudoCmdGroup memberDenyCmd: Single_CMD|SudoCmdGroup memberHost: Single_Host|ipaNetGroup ??? ^ The Schema Design originally suggested that for an ipaSudoRule an ipaHostGroup would be used. http://www.freeipa.org/page/SUDO_Schema_Design#Why_we_must_support_netgroups_in_the_SUDO_rules.3F Last paragraph of the section. Also see last open question and answer to it on the page :-) However... read further... This ipaHostGroup would then be duplicated into a ipaNetGroup (Managed Entry). This ipaNetGroup would then be translated into an ldap backed nisNetGroup (Compat). I am ok changing the sudorule plugin to point memberHost to an ipaNetgroup, however, I think we need to be correct and clear in all the previous references. There are a LOT of moving parts behind the scenes to make this work natively, so the chance for confusion is very high. What I was suggesting, was that perhaps its not necessary to change the sudorule plugin if the eventual end goal is to utilize hostgroups natively. The compat pieces and Managed Entry pieces already handle the translation as elegantly as they can given the circumstances. Is there a negative aspect of having the SudoCompat piece look to an ipaHostgroup for its conversion? I just talked to Nalin and you might be right we can eliminate the need to support the netgroups in the sudo rule for hosts altogether. Since each host group will have a corresponding netgroup (until it is explicitly turned off by admin and it can be turned off only when the clients do not need netgroups any more which will be many years from now) the compat plugin can check if there is a corresponding netgroup, and if there is, use netgroup notation in the generated SUDO rule instead of expanding the rule to contain the host attributes verbatim. This looks like a nice and elegant solution but this means that we *require* the use of the host groups with netgroups. So if the deployment has a netgroup that has hosts A,B,C we require the hosts A,B C be put into a host group. If admin just creates a new netgroup with hosts A, B, C in IPA he would not be able to use this netgroup in the SUDO part at all. May be it is Ok. It will really discourage people from using the netgroups. If we can require admins to always create a top level host group for any netgroup they want to have for whatever reason and this is acceptable then we can avoid allowing direct referencing netgroups in the rule and thus do not need to add this capability to SUDO plugin. It will actually save some future work on SSSD too since it would not need to resolve the netgroups - just host groups. After some thinking IMO the right approach would be: 1) Adjust the compat plugin as described above 2) Do not add capability to SODO mgmt plugin to point to the netgroup in the SUDO rule 3) Document the considerations about the netgroups migration (https://fedorahosted.org/freeipa/ticket/37) Thoughts? Thanks! -JR -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
On 12/9/10 11:59 AM, Dmitri Pal d...@redhat.com wrote: http://www.freeipa.org/page/SUDO_Schema_Design#Why_we_must_support_netgrou ps_in_the_SUDO_rules.3F Last paragraph of the section. Also see last open question and answer to it on the page :-) However... read further... Ah Ha! I just talked to Nalin and you might be right we can eliminate the need to support the netgroups in the sudo rule for hosts altogether. Since each host group will have a corresponding netgroup (until it is explicitly turned off by admin and it can be turned off only when the clients do not need netgroups any more which will be many years from now) the compat plugin can check if there is a corresponding netgroup, and if there is, use netgroup notation in the generated SUDO rule instead of expanding the rule to contain the host attributes verbatim. This looks like a nice and elegant solution but this means that we *require* the use of the host groups with netgroups. So if the deployment has a netgroup that has hosts A,B,C we require the hosts A,B C be put into a host group. If admin just creates a new netgroup with hosts A, B, C in IPA he would not be able to use this netgroup in the SUDO part at all. May be it is Ok. It will really discourage people from using the netgroups. If we can require admins to always create a top level host group for any netgroup they want to have for whatever reason and this is acceptable then we can avoid allowing direct referencing netgroups in the rule and thus do not need to add this capability to SUDO plugin. It will actually save some future work on SSSD too since it would not need to resolve the netgroups - just host groups. Agreed. As a side note to think about: Currently, with the proposed Managed Plungins, netgroups which are created as a result of the hostgroup creation, are not searchable via the IPA Cli. This requested by Item #3 (https://fedorahosted.org/freeipa/ticket/543). This generally means that by default, all hostgroups get an implied (but invisible) netgroup. The only netgroups that turn up in the search are those created directly through the cli. Not sure how this effects the greater world at large. After some thinking IMO the right approach would be: 1) Adjust the compat plugin as described above 2) Do not add capability to SODO mgmt plugin to point to the netgroup in the SUDO rule 3) Document the considerations about the netgroups migration (https://fedorahosted.org/freeipa/ticket/37) I agree, this sounds like the most sane path to follow. I do think it would be courteous to the potential nis/netgroup users of the world, for us to be very clear about the backend behavior regarding the Managed Entries though. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
On Thu, Dec 09, 2010 at 02:59:55PM -0500, Dmitri Pal wrote:
1) Adjust the compat plugin as described above
Attached for testing. Patch 0001 we've seen before; 0002's new.
Nalin
From 1afcb4d6163f5b8137cb1f2e832714e046345ca7 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 30 Nov 2010 18:25:33 -0500
Subject: [PATCH 1/2] sudo and netgroup schema compat updates
- fix quoting of netgroup entries
- don't bother looking for members of netgroups by looking for entries
which list memberOf: $netgroup -- the netgroup should list them as
member values
- use newer slapi-nis functionality to produce cn=sudoers
- drop the real cn=sudoers container to make room for the compat
container
---
install/share/bootstrap-template.ldif |6 -
install/share/schema_compat.uldif | 37
ipa.spec.in |2 +-
3 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/install/share/bootstrap-template.ldif
b/install/share/bootstrap-template.ldif
index 4f10f07..81eb5d6 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
objectClass: nsContainer
cn: sudorules
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
dn: cn=etc,$SUFFIX
changetype: add
objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif
b/install/share/schema_compat.uldif
index 22e3141..52c8d5a 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -47,7 +47,6 @@ default:schema-compat-entry-attribute: objectclass=posixGroup
default:schema-compat-entry-attribute: gidNumber=%{gidNumber}
default:schema-compat-entry-attribute: memberUid=%{memberUid}
default:schema-compat-entry-attribute: memberUid=%deref(member,uid)
-default:schema-compat-entry-attribute:
memberUid=%referred(cn=users,memberOf,uid)
dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
add:objectClass: top
@@ -56,14 +55,42 @@ add:cn: ng
add:schema-compat-container-group: 'cn=compat, $SUFFIX'
add:schema-compat-container-rdn: cn=ng
add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
add:schema-compat-entry-rdn: cn=%{cn}
add:schema-compat-entry-attribute: objectclass=nisNetgroup
add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
-add:schema-compat-entry-attribute:
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute:
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute:
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter:
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute:
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute:
'sudoUser=%ifeq(userCategory,all,ALL,%deref_f(\memberUser\,\(objectclass=posixAccount)\,\uid\))'
+add:schema-compat-entry-attribute:
'sudoUser=%ifeq(userCategory,all,ALL,%deref_rf(\memberUser\,\((objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\,\member\,\(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\,\uid\))'
+add:schema-compat-entry-attribute:
'sudoUser=%ifeq(userCategory,all,ALL,%%%deref_f(\memberUser\,\(objectclass=posixGroup)\,\cn\))'
+add:schema-compat-entry-attribute:
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
I just had a chance to revisit this. It appears that the host piece still doesn't work quite right. This time, I am missing the sudoHost translation entirely. dn: ipaUniqueID=e52c8e06-0315-11e0-b2dd-8a3d259cb0b9,cn=sudorules,dc=example,dc =com objectClass: ipaassociation objectClass: ipasudorule ipaEnabledFlag: TRUE cn: devel ipaUniqueID: e52c8e06-0315-11e0-b2dd-8a3d259cb0b9 memberAllowCmd: cn=readonly,cn=sudocmdgroups,cn=accounts,dc=example,dc=com memberHost: cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com memberUser: cn=ops,cn=groups,cn=accounts,dc=example,dc=com dn: cn=devel,cn=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ops sudoCommand: /usr/bin/less cn: devel On 11/30/10 3:38 PM, Nalin Dahyabhai na...@redhat.com wrote: This is what I've got now; I think it's correct. - fix quoting in the netgroup compat configuration entry - don't bother looking for members of netgroups by looking for entries which list memberOf: $netgroup -- the netgroup should list them as member or memberUser or memberHost values - use newer slapi-nis functionality to produce cn=sudoers - drop the real cn=sudoers container to make room for the compat container Feel free to adjust the schema-compat-container-group for the cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config entry -- the location of the compat sudo entries is of no concern to me. Cheers, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
This is what I see when I manually add the ipaSudoRule entry to my test server: dn: cn=devel,cn=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ops sudoHost: auth4.ops.expertcity.com sudoCommand: /usr/bin/less cn: devel That's assuming the group and host entries you're using are still the same as the sample ones from a while back, of course. In the currently proposed configuration, the expansion of memberHost attribute values depends on functionality that's new in slapi-nis 0.20 and later. Which version are you using? Nalin After a refresh: I can confirm that I also have the same info as you. I guess the piece that is still missing then is: Instead of: sudoHost: hostname.com It should be: sudoHost: +production - which is the group assigned to the ipasudorule. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
On Wed, Dec 08, 2010 at 11:12:34PM +, JR Aquino wrote: I guess the piece that is still missing then is: Instead of: sudoHost: hostname.com It should be: sudoHost: +production - which is the group assigned to the ipasudorule. The memberHost cn=prod,cn=hostgroups,cn=accounts,dc=example,dc=com in the rule is a hostgroup but not a netgroup, so I think it's doing the right thing by resolving the group down to its members' names. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] sudo and netgroup schema compat updates
This is what I've got now; I think it's correct.
- fix quoting in the netgroup compat configuration entry
- don't bother looking for members of netgroups by looking for entries
which list memberOf: $netgroup -- the netgroup should list them as
member or memberUser or memberHost values
- use newer slapi-nis functionality to produce cn=sudoers
- drop the real cn=sudoers container to make room for the compat
container
Feel free to adjust the schema-compat-container-group for the
cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config entry -- the
location of the compat sudo entries is of no concern to me.
Cheers,
Nalin
From 9baefea23f5b944d244eed4bef3f85df3203ae45 Mon Sep 17 00:00:00 2001
From: Nalin Dahyabhai na...@redhat.com
Date: Tue, 30 Nov 2010 18:25:33 -0500
Subject: [PATCH] sudo and netgroup schema compat updates
- fix quoting in the netgroup compat configuration entry
- don't bother looking for members of netgroups by looking for entries
which list memberOf: $netgroup -- the netgroup should list them as
member or memberUser or memberHost values
- use newer slapi-nis functionality to produce cn=sudoers
- drop the real cn=sudoers container to make room for the compat
container
---
install/share/bootstrap-template.ldif |6 -
install/share/schema_compat.uldif | 37
ipa.spec.in |2 +-
3 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/install/share/bootstrap-template.ldif
b/install/share/bootstrap-template.ldif
index 7946526..283d226 100644
--- a/install/share/bootstrap-template.ldif
+++ b/install/share/bootstrap-template.ldif
@@ -64,12 +64,6 @@ objectClass: top
objectClass: nsContainer
cn: sudorules
-dn: cn=SUDOers,$SUFFIX
-changetype: add
-objectClass: nsContainer
-objectClass: top
-cn: SUDOers
-
dn: cn=etc,$SUFFIX
changetype: add
objectClass: nsContainer
diff --git a/install/share/schema_compat.uldif
b/install/share/schema_compat.uldif
index 22e3141..52c8d5a 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -47,7 +47,6 @@ default:schema-compat-entry-attribute: objectclass=posixGroup
default:schema-compat-entry-attribute: gidNumber=%{gidNumber}
default:schema-compat-entry-attribute: memberUid=%{memberUid}
default:schema-compat-entry-attribute: memberUid=%deref(member,uid)
-default:schema-compat-entry-attribute:
memberUid=%referred(cn=users,memberOf,uid)
dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config
add:objectClass: top
@@ -56,14 +55,42 @@ add:cn: ng
add:schema-compat-container-group: 'cn=compat, $SUFFIX'
add:schema-compat-container-rdn: cn=ng
add:schema-compat-check-access: yes
-add:schema-compat-search-base: 'cn=ng,cn=alt,$SUFFIX'
-add:schema-compat-search-filter: !(cn=ng)
+add:schema-compat-search-base: 'cn=ng, cn=alt, $SUFFIX'
+add:schema-compat-search-filter: (objectclass=ipaNisNetgroup)
add:schema-compat-entry-rdn: cn=%{cn}
add:schema-compat-entry-attribute: objectclass=nisNetgroup
add:schema-compat-entry-attribute: 'memberNisNetgroup=%deref_r(member,cn)'
-add:schema-compat-entry-attribute:
'memberNisNetgroup=%referred_r(cn=ng,memberOf,cn)'
-add:schema-compat-entry-attribute:
nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})
+add:schema-compat-entry-attribute:
'nisNetgroupTriple=(%link(%ifeq(\hostCategory\,\all\,\\,\%collect(\\\%{externalHost}\\\,\\\%deref(\\\memberHost\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\member\\\,\\\fqdn\\\)\\\,\\\%deref_r(\\\memberHost\\\,\\\member\\\,\\\fqdn\\\)\\\)\),-,,,%ifeq(\userCategory\,\all\,\\,\%collect(\\\%deref(\\\memberUser\\\,\\\uid\\\)\\\,\\\%deref_r(\\\member\\\,\\\uid\\\)\\\,\\\%deref_r(\\\memberUser\\\,\\\member\\\,\\\uid\\\)\\\)\),-),%{nisDomainName:-})'
+
+dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
+add:objectClass: top
+add:objectClass: extensibleObject
+add:cn: sudoers
+add:schema-compat-container-group: 'cn=SUDOers, $SUFFIX'
+add:schema-compat-search-base: 'cn=sudorules, $SUFFIX'
+add:schema-compat-search-filter:
((objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))
+add:schema-compat-entry-rdn: cn=%{cn}
+add:schema-compat-entry-attribute: objectclass=sudoRole
+add:schema-compat-entry-attribute:
'sudoUser=%ifeq(userCategory,all,ALL,%{externalUser})'
+add:schema-compat-entry-attribute:
