On Fri, Feb 08, 2013 at 01:23:25PM -0500, Dmitri Pal wrote:
> On 02/06/2013 11:13 AM, Sumit Bose wrote:
>> Hi,
>>
>> I tried to extract some common requirements of #1534 'Integrate SSSD
>> with CIFS client' and #1557 'Use the Global Catalog in SSSD for the AD
>> provider' in the
>>
https://fedorahosted.org/sssd/wiki/DesignDocs/NSSResponderIDMappingCalls
>> design page. Currently there is no specific ticket for this, I think it
>> can be opened if the design is accepted.
>>
>> For your convenience the content can be found below as well.
>>
>> bye,
>> Sumit
>>
>>
>> == ID Mapping calls for the NSS responder ==
>> Related tickets:
>> * [
https://fedorahosted.org/sssd/ticket/1534 RFE Integrate SSSD with CIFS
client]
>> * [
https://fedorahosted.org/sssd/ticket/1557 RFE Use the Global Catalog in SSSD
for the AD provider]
>> * [
https://fedorahosted.org/sssd/ticket/1559 RFE Use the getpwnam()/getgrnam()
interface as a gateway to resolve SID to Names]
>>
>> Related design documents:
>> * [
https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient
Integrate SSSD with CIFS Client]
>> * [
https://fedorahosted.org/sssd/wiki/DesignDocs/GlobalCatalogLookups Global
Catalog Lookups in SSSD]
>>
>> === Problem Statement ===
>> When SSSD is used in environments with AD, either as a member of the AD domain or
as a member of a trusted IPA domain, it has to map users and groups managed by AD to a
POSIX ID. The AD user and groups are identified by
>> * a name which may change
>> * a unique SID which never changes, i.e. new SID == new object
>>
>> Applications interacting tightly with users and groups from AD domains e.g.
>> * samba
>> * cifs-client
>> * FreeIPA
>> need to know which SID relates to which POSIX ID or name.
>>
>> Mapping a SID to a user or group would be possible with the current interfaces as
described in ticket #1559. But getting a SID for a user or a group would be at least hard
and ugly if not impossible. I think the solution proposed in ticket #1559 is a good and
useful shortcut. But by making the *bySID lookups also available via a new calls
applications will have a more reliable interface, e.g. by allowing more specific error
codes (see details below).
>>
>> === Overview of the solution ===
>>
>> === Implementation details ===
>> The NSS responder will be extended with four new calls:
>> {{{
>> SSS_NSS_GETSIDBYNAME = 0x0111, /**< Takes a zero terminated fully qualified
name
>> and returns the zero terminated string
representation
>> of the SID of the object with the given
name.
>> */
>> SSS_NSS_GETSIDBYID = 0x0112, /**< Takes an unsigned 32bit integer (POSIX
ID)
>> and returns the zero terminated string
representation
>> of the SID of the object with the given ID.
>> */
>> SSS_NSS_GETNAMEBYSID = 0x0113, /**< Takes the zero terminated string
representation
>> of a SID and returns the zero terminated
fully
>> qualified name of the related object.
>> */
>> SSS_NSS_GETIDBYSID = 0x0114, /**< Takes the zero terminated string
representation
>> of a SID and returns and returns the POSIX ID
of
>> the related object as unsigned 32bit integer
value
>> and another unsigned 32bit integer value
indicating
>> the type (unknown, user, group, both) of the
object.
>> */
>> }}}
>>
>> Alternatively SSS_NSS_GETSIDBYID and SSS_NSS_GETIDBYSID could be implemented to
take an return arrays SIDs and POSIX IDs respectively as the related cifs_idmap API calls
(see [
https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient Integrate
SSSD with CIFS Client]). I took the approach mentioned above because it better matches the
other NSS responder calls and additionally I do not like the implicit required ordering in
the input and output array.
>>
>> After receiving the request the NSS responder will first check if it can create
the response from cached data. If not the request is forwarded to the providers. For the
*byName and *byID calls the corresponding existing interface can be used. For the *bySID
call a new call must be added to the providers. Currently only the IPA and AD provider
will support the new calls. If the provider cannot handle the requests it will return an
appropriate error code which it return to the client via the NSS responder.
>>
>> Additionally on the provider side it must be ensured that the string
representation of the SID is saved in the cache. It looks that this is already the case
for the AD provider. But I think this is currently not the case for the IPA provider for
both IPA and trusted users. Also the PAC responder should add the SID to the cache
object.
>>
>> The sid2name extended operation on the FreeIPA server should get a new request
type and corresponding response types so that the SID is returned with the user and group
data. (A ticket for this should be opened for FreeIPA if this design is approved.)
>>
>> ==== C-API ====
>> The C-API for those calls will be made available in a new library
libsss_nss_idmap (other names are welcome). In contrast to libnss_sss loaded via glibc
into client programs the new library can be linked with other programs. The new calls will
be declared in a header sss_nss_idmap.h and can have reasonable return values to make
error detection an reporting easier for the clients using the new API.
>>
>> {{{
>> /**
>> * @brief Find SID by fully qualified name
>> *
>> * @param[in] fq_name Fully qualified name of a user or a group
>> * @param[out] sid String representation of the SID of the requested user or
group,
>> must be freed by the caller
>> *
>> * @return
>> * - 0 (EOK): success, sid contains the requested SID
>> * - ENOENT: requested object was not found in the domain extracted from the
given name
>> * - ENETUNREACH: SSSD does not know how to handle the domain extracted from the
given name
>> * - ENOSYS: this call is not supported by the configured provider
>> * - EINVAL: input cannot be parsed
>> * - EIO: remote servers cannot be reached
>> * - EFAULT: any other error
>> */
>> int sss_nss_getsidbyname(const char *fq_name, char **sid);
>>
>> /**
>> * @brief Find SID by a POSIX UID or GID
>> *
>> * @param[in] id POSIX UID or GID
>> * @param[out] sid String representation of the SID of the requested user or
group,
>> must be freed by the caller
>> *
>> * @return
>> * - see #sss_nss_getsidbyname
>> */
>> int sss_nss_getsidbyid(uint32_t id, char **sid);
>>
>> /**
>> * @brief Return the fully qualified name for the given SID
>> *
>> * @param[in] sid String representation of the SID
>> * @param[out] fq_name Fully qualified name of a user or a group,
>> must be freed by the caller
>> *
>> * @return
>> * - see #sss_nss_getsidbyname
>> */
>> int sss_nss_getnamebysid(const char *sid, char **fq_name);
>>
>> /**
>> * @brief Return the POSIX ID for the given SID
>> *
>> * @param[in] sid String representation of the SID
>> * @param[out] id POSIX ID related to the SID
>> * @param[out] id_type Type of the object related to the ID
>> *
>> * @return
>> * - see #sss_nss_getsidbyname
>> */
>> int sss_nss_getidbysid(const char *sid, uint32_t *id, enum id_type id_type);
>> }}}
>>
>> Currently I do not see a strong requirement to allow different kind of memory
allocators (e.g. talloc).
>>
>> I think it is not necessary to add special set of return values/error code but
the standard ones are sufficient. Maybe ENETUNREACH it indicate that SSSD could not find
the right domain for the request could be replaced by a better one. (EDOM would be a
candidate, but imo it should be reserved for mathematical operations.)
>>
>> ==== Python bindings ====
>> To allow easy usage of the new calls by the FreeIPA python framework, python
binding would be useful.
>>
>> ==== Lookup utility ====
>> A small utility sss_idmap (other names are welcome) will be added which offers
access to the new calls via libsss_nss_idmap. This utility will make testing easier and
might help user and administrators as well.
>>
>> {{{
>> # sss_idmap --help
>> Usage: sss_idmap [OPTION...]
>> -n, --name-to-sid=NAME Converts name to sid
>> -s, --sid-to-name=SID Converts sid to name
>> -S, --sid-to-id=SID Converts sid to POSIX ID
>> -i, --id-to-sid=ID Converts POSIX ID to sid
>>
>> Help options:
>> -?, --help Show this help message
>> --usage Display brief usage message
>> }}}
>>
>> === How to test ===
>> The sss_idmap utility or the python bindings can be used to create tests, e.g.
>>
>> {{{
>> # sss_idmap --sid-to-name=S-1-5-21-111111-222222-333333-1234
>> DOM\user
>> # sss_idmap --name-to-sid=DOM\user
>> S-1-5-21-111111-222222-333333-1234
>> # sss_idmap --sid-to-name=abcdefg
>> Usage: sss_idmap .......
>> Invalid SID
>> }}}
>>
>> === Author(s) ===
>> Sumit Bose <sbose(a)redhat.com>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> So far makes sense.
> Who are the potential consumers of the library other than the utility?
> Is it CIFS utils? Should we reach out to the CIFS community for the
> follow up integration?
yes, CIFS utils will use it, but we will provided the plugin as part of
https://fedorahosted.org/sssd/ticket/1534 .
Does the design of the plugin belong to the same page? I suspect yes.
Please add a section about it.
> Any other consumers? Desktop?
If all is in place (global catalog lookup, support for trusted domains)
FreeIPA will used it instead of winbind.
Yeah, I continue to forget that IPA grew a dependency on winbind for this.
Yes sure this makes perfect sense to drap the dependency and use SSSD
and its interface.
Please then open a ticket for switching IPA to use this interface.
Should we have design for this switch to be covered on the same design page?
However I wonder whether this interface should follow the same
architecture as we have for other components. I.e.:
* thin client lib is used by the app
* this lib talks to responder over local socket
* responder deals with getting data from cache or triggering provider
asynchronously.
It seems that this architecture is somewhat implied. I sort of figured
it our by rereading the design couple times.
But it requires a bit of knowledge of prior art. Can this part be clarified?
May be a diagram would be helpful?
A draft one is attached.
bye,
Sumit
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
>
www.redhat.com/carveoutcosts/
>
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?