On 11/23/2015 02:08 PM, Jakub Hrozek wrote:
On Fri, Nov 20, 2015 at 12:25:15PM +0100, Pavel Březina wrote:
>
https://fedorahosted.org/sssd/wiki/DesignDocs/SUDOIPASchema
>
> = IPA sudo schema support =
>
> Related ticket(s):
> *
https://fedorahosted.org/sssd/ticket/1108
>
> Related design document(s)
> *
https://fedorahosted.org/sssd/wiki/DesignDocs/SUDOCachingRules
>
> == Problem statement ==
>
> SSSD supports only standard sudo ldap schema at the moment. This has a
> drawback of having the need to run compat plugin that converts IPA sudo
> schema into the standard one. Once SSSD has support for IPA schema
> administrators administrators can disable sudo compat tree which will result
> in performance improvement.
The wiki page should specify that the performance improvement will
happen on the server.
Noted.
>
> == Use cases ==
>
> * compat plugin may be disabled when using IPA sudo provider
>
> == IPA sudo schema ==
>
> IPA sudo schema is rather different than the standard one. This section
> contains the description of this schema together with ldap containers where
> sudo rules are stored. A relevant standard attribute is noted when possible.
> '''RDN is marked in bold'''. Attributes that hold dn are
marked in italic.
>
> ==== cn=sudocmds,cn=sudo,$dc ====
>
> This container contains definition of single commands that may be present in
> sudo rules.
>
> * objectClass = ipasudocmd
> * '''ipaUniqueID'''
> * sudoCmd ~ sudoCommand
> * ''memberOf'' (dn of sudo command group)
>
> ==== cn=sudocmdgroups,cn=sudo,$dc ====
>
> This container contains definition of command groups that may be present in
> sudo rules.
>
> * objectClass = ipasudocmdgroup
> * ipaUniqueID
> * '''cn'''
> * ''member'' (dn of sudo command)
>
> ==== cn=sudorules,cn=sudo,$dc ====
>
> This container contains definition of sudo rules.
>
> * objectClass = ipasudorule
> * '''ipaUniqueID'''
> * cn
> * ipaEnabledFlag
>
> * ipaSudoOpt ~ sudoOption
> * ''ipaSudoRunAs'' ~ sudoRunAsUser (dn of user or group of users)
> * ''ipaSudoRunAsGroup'' ~ sudoRunAsGroup (dn of group)
> * ''memberAllowCmd'' (dn of sudo command or command group)
> * ''memberDenyCmd'' (dn of sudo command or command group)
> * ''memberHost'' ~ sudoHost (dn of ipa enrolled machine or
hostgroup)
> * ''memberUser'' ~ sudoUser (dn of user or group of users)
> * hostMask (ip/mask)
>
> The following attibures have a special meaning and can contain only value
> "all". For example if cmdCategory is present, it is equivalent to
> sudoCommand=ALL.
>
> * cmdCategory ~ sudoCommand
> * hostCategory ~ sudoHost
> * ipaSudoRunAsGroupCategory ~ sudoRunAsGroup
> * ipaSudoRunAsUserCategory ~ sudoRunAsUser
> * userCategory ~ sudoUser
>
> The following attributes are used to contain external objects not known to
> IPA nor SSSD. Since SSSD by design provides rules only to users and groups
> known to it, we can safely ignore those attributes.
>
> * externalHost
> * externalUser
> * ipaSudoRunAsExtGroup
> * ipaSudoRunAsExtUser
>
> == Overview of the solution ==
>
> We will again use rules, smart and full refresh similar to what we do in
> ldap provider. Since we are working with three containers, it is not very
> simply to translate everything at once into current standard sudo schema
> that we use inside SSSD, because it would make changes in commands and
> command groups hard to propagate. Instead we will keep command and command
> groups stored separately and translate it into sudoCommand in responder on
> the fly.
Do you already have an idea how to accomplish this? It would be best if
the responder did as little processing as possible. Do you think it
would be a good idea to use the member/memberof links so that on the
responder side we can grab all the commands and command groups in a
single ASQ query?
Yes, I would like to do ASQ.
> We will take advantage of using an IPA server and translate dn
into names by
> parsing dn when possible.
You mean read the name out of the DN directly?
Yes. We do it in nested groups for example so I think we can use this to
avoid more ldap requests.
>
> == Implementation details ==
>
> ==== Full refresh ====
>
> * download everything under cn=sudo,$dc that applies to this host
> * store only commands and command groups that are present in at least one
> rule
> * convert what possible to sudo schema but leave references to commands and
> command groups for further processing in responder
>
> ==== Smart refresh ====
>
> * download everything under cn=sudo,$dc that applies to this host newer than
> last usn value
> * if new command or command group is downloaded store it only if it is
> present in changed rule
> * if a rule contains command or command group that is not yet present in
> sysdb, fetch it with dereference or single lookup
>
> ==== Rules refresh ====
>
> * refresh expired rules and commands and command groups that are present in
> those rules
>
> === Configuration changes ===
>
> * new option sudo_schema = [ipa|native]
I would actually do it the other way around or even just let the admin
choose by selecting a non-default ldap_sudo_search_base. But I think we
should use the new schema by default.
What do you mean by the other way around?
>
> === How To Test ===
>
> * existing tests can be used, only switching ldap server for IPA
I think this part should say that the server is the same, but the schema
or options are different.
>
> === Authors ===
>
> * Pavel Březina <pbrezina(a)redhat.com>