On ke, 12 loka 2016, Robert Sturrock wrote:
Hi All.
We’re attempting to setup an IPA (4.2) service on RHEL7.2 to provide
better connectivity to our (large) organisational AD service for Linux
clients.
We have setup IPA and configured a suitable AD trust (with SID POSIX
mapping) in the hope that users will be able to access IPA resources
(hosts, storage) using existing AD credentials and groups. This
working fine - we can login to Linux hosts using AD credentials and see
the AD groups.
However, it would appear that in order to use AD group membership as
the basis for Linux HBAC or sudo, we need to firstly _map_ the AD
groups to an equivalent IPA (POSIX) group? Is this correct?
In HBAC and SUDO rules you need to make sure two things are in place:
- on the host level the identities which are subject to the rules are
available in POSIX namespace
- on the LDAP server level the identities which are subject to the rules
are real LDAP objects in IPA LDAP server. This is how LDAP schema is
built.
AD users and groups do not exist in IPA LDAP server, thus they need to
be somehow presented there. This is important technical limitation, an
alternative to which is inherent integrity inconsistency. We don't want
to have inconsistent data relationships.
'External' groups are means to solve this, thanks to the nested group
support in IPA LDAP. On the host level SSSD translates these 'external'
group members to POSIX identities and since POSIX group namespace is
flat, this works well.
I can see that it’s possible to define ‘external’ *users* (not groups)
in some cases, but this function appears to be deprecated.
You don't need to map groups only, the mechanism we built allows you to
specify any resolvable (by SSSD on IPA master) SID of an object from
Active Directory. This means that specifying
ipa group-add-member my_external_group --external 'AD\ShinyUser'
is going to work in the same way as
ipa group-add-member my_external_group --external 'AD\Shiny Members'
-- as long as SIDs for 'AD\ShinyUser' and 'AD\Shiny Members' objects are
resolvable by SSSD on the IPA master in question, you can add them as
members of the 'my_external_group'. Your 'my_external_group' can have a
mixture of members and SSSD will do a resolution of those when
performing HBAC rules checks. This all works because POSIX namespace has
no nested groups, so any nested group membership that leads
'AD\ShinyUser' to be a member of a POSIX group will result in
'AD\ShinyUser' to be treated as a member of a POSIX group in question.
Where did you find a sign or statement that mapping 'external' users is
a deprecated feature?
We have large numbers of groups in our AD (~50k), so obviously that’s a
lot of mapping!
Do you really need to have all ~50K groups mapped to assign access controls on
the Linux side? While those ~50K on the AD side may make sense for AD
access, we found out that in many cases access patterns on the Linux
side are quite different to the group distribution on AD side so people
end up creating a different group distribution, thus making the use of
'external' groups a feature rather than a limitation.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
