[Freeipa-devel] [PATCH] 352-354 Add support for AD users to hbactest command

Martin Kosek mkosek at redhat.com
Wed Feb 13 16:17:42 UTC 2013


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.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-352-4-generalize-ad-gc-search.patch
Type: text/x-patch
Size: 12565 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130213/a5aedc86/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-353-4-do-not-hide-sid-resolver-error-in-group-add-member.patch
Type: text/x-patch
Size: 1377 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130213/a5aedc86/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-354-4-add-support-for-ad-users-to-hbactest-command.patch
Type: text/x-patch
Size: 11842 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130213/a5aedc86/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-hbachelp-examples-formatting.patch
Type: text/x-patch
Size: 3794 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130213/a5aedc86/attachment-0003.bin>


More information about the Freeipa-devel mailing list