[Freeipa-devel] [RFC] Extdom plugin enhancement: grouplist
Sumit Bose
sbose at redhat.com
Fri Jun 6 17:24:14 UTC 2014
Hi,
I've created a design page about enhancing the extdom plugin to send the
list of groups of a user together with the POSIX data to IPA clients
with SSSD at
http://www.freeipa.org/page/V4/Extdom_plugin_enhancement_grouplist
For your convenience the text can be found below as well.
Comments and suggestions are welcome.
bye,
Sumit
= Overview =
Currently on FreeIPA clients the full list of group-memberships for
users from trusted domains is only available for authenticated users.
Authentication is needed because the group-memberships are extracted
from the PAC which is a part of the Kerberos ticket of the user. For
un-authenticated users only the primary POSIX group is available.
With the introduction of SSSD's ipa-server-mode IPA servers can resolve
the group memberships for user from trusted domains even for
un-authenticated users by reading them from the AD DCs of the trusted
domains directly. This data should be made available to the IPA clients
as well.
= Use Cases =
* Calling the 'id' command on a IPA client or calling getgrouplist() in
* a process should return the full list of secondary groups for any user
* from a trusted domain without requiring that the user has to log in
* first
** [https://fedorahosted.org/freeipa/ticket/4031 RFE Support initgroups
for unauthenticated AD users] FreeIPA ticket
** [https://fedorahosted.org/sssd/ticket/2159 RFE Support initgroups for
unauthenticated AD users] SSSD ticket
= Design =
The IPA extdom plugin is already called by SSSD running on the IPA
clients to translate SID to names or POSIX IDs. It can be enhanced to
return the secondary groups as well.
To make this change backward compatible in the sense that newer client
can still work with older servers
* a new OID can be added to the extdom plugin, currently it uses
* 2.16.840.1.113730.3.8.10.4 , if we agree on this approach it might be
* possible to just add a ".1" to the OID. With this the client can
* determine from reading the rootDSE if the server supports this
* operation or not.
* the client just sends the new request and assumes in the case of a
* specific error the request is not supported. A suitable error code
* might be LDAP_UNWILLING_TO_PERFORM which is currently only returned by
* the extdom plugin if either there is no request data or if there are
* issues reading and understanding the first enumeration in the request
* data (see Implementation section for more details).
If the request was parsed successful the extdom plugin will return the
secondary groups for the given user as a list of fully qualified group
names. Additionally the POSIX user data (UID, GID, gecos, home-directory
and shell) can be send. This would reduce the number of requests to the
extdom plugin, because refreshing user and group-membership data often
happen together. Please note that UID and GID may change due to
user-views. But as long as this feature is implemented after user-views
everything what is needed will be available.
= Implementation =
== Request ==
The current request looks like this:
/* We expect the following request:
* ExtdomRequestValue ::= SEQUENCE {
* inputType ENUMERATED {
* sid (1),
* name (2),
* posix uid (3),
* posix gid (3)
* },
* requestType ENUMERATED {
* simple (1),
* full (2)
* },
* data InputData
* }
*
* InputData ::= CHOICE {
* sid OCTET STRING,
* name NameDomainData
* uid PosixUid,
* gid PosixGid
* }
*
* NameDomainData ::= SEQUENCE {
* domain_name OCTET STRING,
* object_name OCTET STRING
* }
*
* PosixUid ::= SEQUENCE {
* domain_name OCTET STRING,
* uid INTEGER
* }
*
* PosixGid ::= SEQUENCE {
* domain_name OCTET STRING,
* gid INTEGER
* }
*/
Basically only a new request type must be added, e.g.
* requestType ENUMERATED {
* simple (1),
* full (2)
* full_with_groups (3)
* },
But as mentioned before the LDAP_UNWILLING_TO_PERFORM error code is only
send if there are issues with the inputType. The requestType is
evaluated later in the existing code and the quite generic
LDAP_OPERATIONS_ERROR error code is returned if an unexpected value is
found. This would make the detection based on error code much more
fragile. I would suggest if we do not want to use a new OID to indicate
the feature, that the inputType is extended as well, e.g. by adding 128
or 256 to the values. Nevertheless I think it is less error prone to use
a new OID.
== Processing the request ==
The extdom plugin will call getgrouplist() and the resolve the fully
qualified names by calling getgrgid(). By default groups from the local
IPA domain are returned unqualified and the local domain name should be
added in this case so that the response only contains fully qualified
group names.
There are two things to note here. First getgrgid() returns the full
list of group members which might cause some unneeded overhead e.g. with
respect to memory allocation. Second easiest way to determine if a
domain name is fully qualified is to look for a '@' character. But this
will only work if the full_name_format option is not changed from the
default. Both can be fixed by adding a call to libsss_nss_idmap to map a
GID to user and domain name. If it turns out the such a call is needed
it can be added later and the extdom plugin can be updated accordingly.
Additionally the extdom plugin call getpwnam() with user-view code to
get the data of the POSIX user entry.
== Response ==
Currently the response looks like:
/* We send to follwing response:
* ExtdomResponseValue ::= SEQUENCE {
* responseType ENUMERATED {
* sid (1),
* name (2),
* posix_user (3),
* posix_group (4)
* },
* data OutputData
* }
*
* OutputData ::= CHOICE {
* sid OCTET STRING,
* name NameDomainData,
* user PosixUser,
* group PosixGroup
* }
*
* NameDomainData ::= SEQUENCE {
* domain_name OCTET STRING,
* object_name OCTET STRING
* }
*
* PosixUser ::= SEQUENCE {
* domain_name OCTET STRING,
* user_name OCTET STRING,
* uid INTEGER
* gid INTEGER
* }
*
* PosixGroup ::= SEQUENCE {
* domain_name OCTET STRING,
* group_name OCTET STRING,
* gid INTEGER
* }
*/
Here a new responds type e.g.
posix_user_grouplist (5)
is needed which returns OutputData
user_grouplist PosixUserGrouplist
as
PosixUser ::= SEQUENCE {
domain_name OCTET STRING,
user_name OCTET STRING,
uid INTEGER
gid INTEGER
gecos OCTET STRING,
home_directory OCTET STRING,
shell OCTET STRING,
grouplist GroupNameList
}
GroupNameList ::= SEQUENCE OF groupname OCTET STRING
Since the new response type will only be returned if requested by the
client there are no compatibility concerns because older clients cannot
request it.
=Feature Management =
The extdom plugin is automatically configured during
ipa-adtrust-install. No additional configuration is needed.
== UI ==
n/a
== CLI ==
n/a
= Major configuration options and enablement =
No additional configuration is needed. If chosen a new OID can indicate
that the feature is available.
= Replication =
n/a
= Updates and Upgrades =
If the extdom plugin is already configured updating the plugin binary
will automatically make the new feature available.
= Dependencies =
n/a
= External Impact =
SSSD must be able to detect the presence of the new feature by checking
to new OID or a LDAP error code.
= Backup and Restore =
n/a
= Test Plan =
Besides running integration tests with a separate IPA client the plugin
can be exercised manually on the server as well and since the extdom
plugin uses standard libc and SSS interfaces IPA users can be requested
via the extdom plugin as well. This mean the plugin can be tested on the
server without established trust which I think would make it possible to
include it in the CI tests as well.
The current version of the extdom plugin can be manually tested in the
following way:
$ cat extdom_req_user_admin.asc
Example Example.Sid2NameRequestValue
inputType 2
requestType 1
data name
data.name.domain_name ipa20.devel
data.name.object_name admin
$ asn1Coding extdom_req.asn extdom_req_user_admin.asc
Parse: done.
var=Example, value=Example.Sid2NameRequestValue
var=inputType, value=2
var=requestType, value=1
var=data, value=name
var=data.name.domain_name, value=ipa20.devel
var=data.name.object_name, value=admin
name:NULL type:SEQUENCE
name:inputType type:ENUMERATED value:0x02
name:requestType type:ENUMERATED value:0x01
name:data type:CHOICE
name:name type:SEQUENCE
name:domain_name type:OCT_STR value:69706132302e646576656c
name:object_name type:OCT_STR value:61646d696e
Coding: SUCCESS
-----------------
Number of bytes=30
30 1c 0a 01 02 0a 01 01 30 14 04 0b 69 70 61 32 30 2e 64 65 76 65 6c 04
05 61 64 6d 69 6e
-----------------
OutputFile=extdom_req_user_admin.out
Writing: done.
$ cat extdom_req_user_admin.out | base64
MBwKAQIKAQEwFAQLaXBhMjAuZGV2ZWwEBWFkbWlu
$ ldapexop -Y GSSAPI
2.16.840.1.113730.3.8.10.4::MBwKAQIKAQEwFAQLaXBhMjAuZGV2ZWwEBWFkbWlu
SASL/GSSAPI authentication started
SASL username: admin at IPA20.DEVEL
SASL SSF: 56
SASL data security layer installed.
# extended operation response
oid: 2.16.840.1.113730.3.8.10.4
data::
MDIKAQEELVMtMS01LTIxLTEyMjMyODkxODgtMzE5ODQ0MDM1My0zMzAwMjExMDMyLTUwMA=
=
$ echo -n
MDIKAQEELVMtMS01LTIxLTEyMjMyODkxODgtMzE5ODQ0MDM1My0zMzAwMjExMDMyLTUwMA==
|base64 -d > extdom_resp_user_admin.bin
$ asn1Decoding extdom_resp.asn extdom_resp_user_admin.bin
Example.Sid2NameResponseValue
Parse: done.
Decoding: SUCCESS
DECODING RESULT:
name:NULL type:SEQUENCE
name:responseType type:ENUMERATED value:0x01
name:data type:CHOICE
name:sid type:OCT_STR
value:532d312d352d32312d313232333238393138382d333139383434303335332d333330303231313033322d353030
$ echo
532d312d352d32312d313232333238393138382d333139383434303335332d333330303231313033322d353030
| xxd -r -p
S-1-5-21-1223289188-3198440353-3300211032-500
= RFE Author =
[[User:Sbose|Sumit Bose]]
More information about the Freeipa-devel
mailing list