[Freeipa-devel] [PATCH] 352-354 Add support for AD users to hbactest command
Martin Kosek
mkosek at redhat.com
Thu Feb 14 07:44:49 UTC 2013
On 02/13/2013 07:38 PM, Alexander Bokovoy wrote:
> On Wed, 13 Feb 2013, Martin Kosek wrote:
>> On 02/13/2013 02:14 PM, Alexander Bokovoy wrote:
>>> On Wed, 13 Feb 2013, Martin Kosek wrote:
>>>> On 02/01/2013 01:35 PM, Martin Kosek wrote:
>>>>> On 01/24/2013 03:04 PM, Simo Sorce wrote:
>>>>>> On Thu, 2013-01-24 at 08:15 +0100, Martin Kosek wrote:
>>>>>>> On 01/23/2013 02:23 PM, Simo Sorce wrote:
>>>>>>>> On Wed, 2013-01-23 at 09:10 +0100, Martin Kosek wrote:
>>>>>>>>> On 01/19/2013 07:35 PM, Simo Sorce wrote:
>>>>>>>>>> On Fri, 2013-01-18 at 18:24 +0100, Martin Kosek wrote:
>>>>>>>>>>> How this works:
>>>>>>>>>>> 1. When a trusted domain user is tested, AD GC is searched
>>>>>>>>>>> for the user entry Distinguished Name
>>>>>>>>>>
>>>>>>>>>> My head is not clear today but it looks to me you are doing 2 searches.
>>>>>>>>>> One to go from samAccountName -> DNa dn then a second for DN -> SID.
>>>>>>>>>>
>>>>>>>>>> Why are you doing 2 searches ? The first one can return you the
>>>>>>>>>> ObjectSid already.
>>>>>>>>>>
>>>>>>>>>> Simo.
>>>>>>>>>
>>>>>>>>> I had to do 2 searches because GC refuses to give me tokenGroups
>>>>>>>>> attribute
>>>>>>>>> content when I do not search with exact DN and LDAP SCOPE_BASE. So I
>>>>>>>>> have to do
>>>>>>>>> the first search to find out the DN of the searched user and then a
>>>>>>>>> second
>>>>>>>>> query to get the tokenGroups (and ObjectSid).
>>>>>>>>
>>>>>>>> I see, yes that makes sense, would you mind adding a comment to this
>>>>>>>> effect so we do not try to 'optimize' at some point ?
>>>>>>>> I have no additional concerns then.
>>>>>>>>
>>>>>>>> Simo.
>>>>>>>>
>>>>>>>
>>>>>>> Hello Simo,
>>>>>>>
>>>>>>> Thanks for review. Anyway, there is already a relevant comment in
>>>>>>> dcerpc.py,
>>>>>>> where the double search is performed:
>>>>>>>
>>>>>>> ...
>>>>>>> def get_trusted_domain_user_and_groups(self, object_name):
>>>>>>> ...
>>>>>>> entries = self.get_trusted_domain_objects(components.get('domain'),
>>>>>>> components.get('flatname'), filter, attrs,
>>>>>>> _ldap.SCOPE_SUBTREE)
>>>>>>>
>>>>>>> # Get SIDs of user object and it's groups
>>>>>>> # tokenGroups attribute must be read with scope BASE to avoid
>>>>>>> search error
>>>>>>> attrs = ['objectSID', 'tokenGroups']
>>>>>>> ...
>>>>>>>
>>>>>>> I think it's enough to avoid "optimizing" this process - we would find out
>>>>>>> the
>>>>>>> "optimization" soon anyway, as the tokenGroups search would return error
>>>>>>> :-)
>>>>>>
>>>>>> Perfect!
>>>>>>
>>>>>> /me just had an eye vision exam, will complain to his doctor :-)
>>>>>>
>>>>>
>>>>> I enhanced the hbactest to also support user SID, not only trusted domain
>>>>> user
>>>>> name. Updated set of patches attached.
>>>>>
>>>>> How it works:
>>>>>
>>>>> # ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 --host
>>>>> `hostname` --service sshd
>>>>> --------------------
>>>>> Access granted: True
>>>>> --------------------
>>>>> Matched rules: can_login
>>>>>
>>>>> Martin
>>>>
>>>> Attaching a rebased set of patches.
>>> Thanks.
>>>
>>> I think we need to account for few more conditions.
>>>
>>> There are following cases:
>>>
>>> - user exists in AD
>>> - user does not exist in AD
>>> - group from AD specified as user
>>>
>>> The latter case is interesting because we can have groups from AD in
>>> external group mappings and people may specify them by mistake in
>>> hbactest. In such case I think we could have stated that group/user
>>> unknown or unmapped.
>>>
>>> Right now I'm getting less than helpful message:
>>> ---------------------------------------------------------------------------
>>> [root at jano ~]# ipa group-show extbar
>>> Group name: extbar
>>> Description: Ext bar
>>> Member of groups: foobar
>>> External member: S-1-5-21-3502988750-125904550-3683905862-512,
>>> S-1-5-21-3502988750-125904550-3683905862-500
>>> [root at jano ~]# ipa group-show foobar
>>> Group name: foobar
>>> Description: foo bar
>>> GID: 944600004
>>> Member groups: extbar
>>> [root at jano ~]# ipa hbactest --user S-1-5-21-3502988750-125904550-3683905862-512
>>> --host `hostname` --service sshd
>>> ipa: ERROR: trusted domain object not found
>>> [root at jano ~]# ipa hbactest --user S-1-5-21-3502988750-125904550-3683905862-500
>>> --host `hostname` --service sshd
>>> --------------------
>>> Access granted: True
>>> --------------------
>>> Matched rules: allow_all
>>> [root at jano ~]# ipa hbactest --user ADX\\Administrator --host `hostname`
>>> --service sshd
>>> --------------------
>>> Access granted: True
>>> --------------------
>>> Matched rules: allow_all
>>> [root at jano ~]# ipa hbactest --user ADX\\Domain\ Admins --host `hostname`
>>> --service sshd
>>> ipa: ERROR: trusted domain object not found
>>> [root at jano ~]# ipa hbactest --user ADX\\Enterprise\ Administrator --host
>>> `hostname` --service sshd
>>> ipa: ERROR: trusted domain object not found
>>> [root at jano ~]# ipa hbactest --user ADX\\DoesNotExist --host `hostname`
>>> --service sshd
>>> ipa: ERROR: trusted domain object not found
>>> -----------------------------------------------------------------------------
>>>
>>> As you can see, group-as-user, unmapped group/user and non-existing AD
>>> user all raise error but the message is quite unclear -- does it talk
>>> about trusted domain itself or some object within the domain? Perhaps
>>> specifying real reason would be more helpful?
>>>
>>> If we are expecting only a user object, then I think we can change
>>> message a bit to state it more clear.
>>>
>>>> - return False
>>>> - return False
>>>> + if not found_flatname:
>>>> + raise errors.ValidationError(name=_('trusted domain object'),
>>>> + error= _('no trusted domain matched the specified
>>>> flat name'))
>>>> + if not entries:
>>>> + raise errors.NotFound(reason=_('trusted domain object not
>>>> found'))
>>>> +
>>>> + return entries
>>>
>>>
>>
>> Fixed. This is quite straightforward as the errors are now returned via
>> specific exceptions and not with False/None result:
>>
>> # ipa hbactest --user "AD\Doesnotexist" --host `hostname` --service sshdipa:
>> ERROR: trusted domain user not found
>>
>> I am not convinced we should create a specific error when a group is passed
>> instead of user. To fix this, we would have to search GC with different filter
>> and also allow (|(objectclass=group)(objectclass=user)) instead of
>> (objectclass=user) which is there now and then check if the resulting object is
>> user or group. I am not convinced we want to do that, the error is now pretty
>> clear that user could not be found...
>>
>> I also extended hbactest help and added a section about testing trusted domain
>> users, I forgot to add it before. I am also attaching a related simple patch
>> fixing formatting for other hbactest examples.
> One more fix and we are done (see below).
>
> Thanks for refinements!
>
>> +HBACTEST AND TRUSTED DOMAINS
>> +
>> +When an external trusted domain is configured in IPA, HBAC rules are also
>> applied
>> +on users accessing IPA resources from the trusted domain. Trusted domain
>> users and
>> +groups (and their SIDs) can be then assigned to external groups which can be
>> +members of POSIX groups in IPA which can be used in HBAC rules and thus
>> allowing
>> +access to resources protected by the HBAC system.
>> +
>> +hbactest plugin is capable of testing access for both local IPA users and users
>> +from the trusted domains, either by a fully qualified user name or by user SID.
>> +Such user names need to have a trusted domain specified as a short name
>> +(DOMAIN\Administrator) or with a user principal name (UPN),
>> Administrator at ad.test.
>> +
>> +Please note that hbactest executed with a trusted domain user as --user
>> parameter
>> +can be only run by members of "trust admins" group.
>> +
>> +EXAMPLES:
>> +
>> + 1. Test if a user from a trusted domain specified by its shortname
>> matches any
>> + rule:
>> +
>> + $ ipa hbactest --user "DOMAIN\Administrator" --host `hostname` --service
>> sshd
> "Domain\Administrator" would not give working \ in most shells. You need
> to use 'Domain\Administrator' for that.
>
>> + 4. Test if other user from a trusted domain specified by its SID matches
>> any rule:
>> +
>> + $ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \\
>> + --host `hostname` --service sshd
>> + --------------------
>> + Access granted: True
>> + --------------------
>> + Matched rules: allow_all
>> + Matched rules: can_login
>> +
>> + 5. Test if other user from a trusted domain specified by its shortname
>> matches
>> + any rule:
>> +
>> + $ ipa hbactest --user "DOMAIN\Otheruser" --host `hostname` --service sshd
> Same here.
>
> Once these fixed, please commit.
Fixed. Pushed to master, ipa-3-1.
Thanks for review both of you!
Martin
More information about the Freeipa-devel
mailing list