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@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@jano ~]# ipa group-show foobar
  Group name: foobar
  Description: foo bar
  GID: 944600004
  Member groups: extbar
[root@jano ~]# ipa hbactest --user S-1-5-21-3502988750-125904550-3683905862-512
--host `hostname` --service sshd
ipa: ERROR: trusted domain object not found
[root@jano ~]# ipa hbactest --user S-1-5-21-3502988750-125904550-3683905862-500
--host `hostname` --service sshd                              
--------------------
Access granted: True
--------------------
  Matched rules: allow_all
[root@jano ~]# ipa hbactest --user ADX\\Administrator --host `hostname`
--service sshd
--------------------
Access granted: True
--------------------
  Matched rules: allow_all
[root@jano ~]# ipa hbactest --user ADX\\Domain\ Admins --host `hostname`
--service sshd
ipa: ERROR: trusted domain object not found
[root@jano ~]# ipa hbactest --user ADX\\Enterprise\ Administrator --host
`hostname` --service sshd
ipa: ERROR: trusted domain object not found
[root@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), 
administra...@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.
--
/ Alexander Bokovoy

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to