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

[Alexander Bokovoy]

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


-- 
/ Alexander Bokovoy