Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1254190
Description of problem: IdM does not accept AD groups to be assigned roles with IdM for RBAC purposes. E.g., an organization's IT Help Desk is represented in Active Directory via a group 'Help Desk'; this groups should be mapped to the role 'helpdesk' in IdM, allowing them to perform basic IT actions such as reseting passwords. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1. In "Role Based Access Control" screen of IdM, select a role such as 'helpdesk' 2. Assign an External Group, mapped to AD 3. Log out, attempt to login as AD user in that member group. Actual results: * Login will fail, so it is not possible to perform actions via Web GUI. * Similar failure with CLI, with a SASL error. Expected results: AD user shuold be allowed to log in, and perform the privileges assigned via RBAC Additional info:
The use case why this was filed: Give some minimal privileges within IdM to Help Desk staff to manage DNS entries or VMWare admins to create computer objects for new guests. Leverage the IDs which are already in AD.
Comment from ab:
To login into UI/CLI, you have to have an LDAP object that could be used to map your Kerberos principal to. AD users have no such principals, thus IPA framework cannot authenticate to IPA LDAP server on their behalf.
Even if we find what to map AD user to, we need to add support to do such mapping dynamically in 389-ds. Right now SASL mapping mechanism takes into account only user and realm names, e.g. Administrator and AD.TEST. As SASL mapping table is defined in cn=config, it is not replicated across IPA servers and should be managed separately, but more important is the fact that we address all AD users/groups in LDAP via their security identifiers (SIDs), not names. Getting Administrator and AD.TEST means nothing -- 389-ds needs to know SID of the user to even map the user to, say, ID override record for this user in 'Default Trust View', and needs to have special code to handle that.
We also cannot use currently a compat tree entry representing AD user to map to because we don't support SASL uthentication for it, only simple LDAP bind. If SASL authentication comes in which tries to map to compat tree entry for AD user, schema compatibility plugin will attempt to use SSSD to perform authentication without passing Kerberos ticket (which it couldn't pass as it wasn't delegated) and will fail because there is no password.
A test done by AB: I did a small hack to slapi-nis plugin that accepts SASL GSSAPI authentication for AD users in the compatibility tree. Coupled with a special SASL mapping rule for 389-ds, this allows at least IPA CLI to proceed with read-only access as we need to add ACIs to allow such users to control their own override entries (which is not easy yet).
[root@m1 ~]# ldapwhoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: Administrator@ADX.TEST SASL SSF: 56 SASL data security layer installed. dn: uid=administrator@adx.test,cn=users,cn=compat,dc=example,dc=com [root@m1 ~]# ipa user-show some.user User login: some.user First name: Some Last name: User Home directory: /home/some.user Login shell: /bin/sh Email address: some.user@example.com UID: 1634400022 GID: 1634400022 Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False [root@m1 ~]# ipa user-mod some.user --shell /bin/bash ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'loginShell' attribute of entry 'uid=some.user,cn=users,cn=accounts,dc=example,dc=com'. [root@m1 ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@ADX.TEST Valid starting Expires Service principal 08/14/2015 07:16:31 08/14/2015 14:39:26 HTTP/m1.example.com@EXAMPLE.COM renew until 08/15/2015 04:39:24 08/14/2015 04:39:49 08/14/2015 14:39:26 ldap/m1.example.com@EXAMPLE.COM renew until 08/15/2015 04:39:24 08/14/2015 04:39:47 08/14/2015 14:39:26 krbtgt/EXAMPLE.COM@ADX.TEST renew until 08/15/2015 04:39:24 08/14/2015 04:39:26 08/14/2015 14:39:26 krbtgt/ADX.TEST@ADX.TEST renew until 08/15/2015 04:39:24
From triage:
A clarification by Alexander: The only real use case we don't have covered right now is to allow AD users to change their own properties via ID overrides. The rest can be done by admins or other IPA users because you can delegate permissions to them however, AD users cannot set up own public ssh keys, shell and home directory to do that someone from IPA (a user in IPA) has to do that right now and by default only IPA admins can create ID overrides so this is clearly missing functionality for AD integration changing our code to allow AD users to manage all IPA objects is more complex
First we need to create permissions that 'replicate' how admins permissions look like, then we need to add a mechanism to interpret SIDs in the external membership of external groups by directory server when considering these AD users 'members' of the external groups. Then we need to allow dirsrv to map properly SASL authenticated DNs to those SIDs. So that external members are recognized as DNs from compat tree
Metadata Update from @pvoborni: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.5 backlog
Login to comment on this ticket.