On 04/23/2014 02:46 PM, Martin Kosek wrote:
On 04/22/2014 01:38 PM, Petr Viktorin wrote:
On 04/16/2014 05:56 PM, Simo Sorce wrote:
On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote:
On Wed, 16 Apr 2014, Martin Kosek wrote:
In general I am not sure all authenticated users need access to all
this
info. Alexander ?
SSSD needs to read some of this information for subdomains support.
That would be at least host/*@REALM who needs to access it.

Can you please list exactly which ones are needed ?
SSSD subdomains support needs:
    - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs
      - ipaNTFlatName
      - ipaNTSecurityIdentifier
      - ipaNTTrustedDomainSID
      - cn

Question is - is there any added value in hiding part of the
trust information from authenticated users? I.e. attributes like
ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this
attribute anyway?), SID blacklists...
Yes. Some of those attributes are needed as internal detail of ipasam --
part of how Samba stores this information taken from specific DCE RPC
structures.

If yes, we would need to split this permission in 2 and have one for
authenticated users and one for "Trust Adminitrators" and "Trust Readers".
Yes. Authenticated users shouldn't get any access to those details:
    ipantsupportedencryptiontypes
    ipanttrustattributes
    ipanttrustauthincoming
    ipanttrustauthoutgoing



Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group
should
then have this permission assigned so that samba can operate the attributes.
'adtrust agents' and 'trust administrators' should have read, modify,
delete, and search on cn=trusts.


Right. We will probably want to turn most of ACIs in
install/updates/60-trusts.update in managed permissions (i.e. defined in
trust.py) and make "adtrust agents" and "trust admins" it's members.
I agree.


+1

Simo.


All right. Now I'm replacing the global anonymous read ACI; converting the
others will come later. The existing agents/admins ACIs grant the 'read' (or
'all') right already.
ipaIDRange is covered in the range plugin, so what's left for this patch is the
ipaNTTrustedDomain/ipaNTDomainAttrs attributes.

Does that sound reasonable?

This is all that's needed from SSSD side, I just verified in sssd git. sssd
indeed only uses these attributes:

#define IPA_CN "cn"
#define IPA_FLATNAME "ipaNTFlatName"
#define IPA_SID "ipaNTSecurityIdentifier"
#define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID"

So I am OK with the patch as is.

However, with this ACI, regular users will not be able to show Trusts with
command line even though they have access to the basic information:

# ipa trust-find
----------------
0 trusts matched
----------------
----------------------------
Number of entries returned 0
----------------------------

IMO trust command should be able to return the information that the user is
allowed to see. I prepared a patch to make the read part of trust.py more
resilient to missing attributes. Attached.

With this patch enabled, I have this output as regular user:

# ipa trust-find
---------------
1 trust matched
---------------
   Realm name: tbad.example.com
   Domain NetBIOS name: TBAD
   Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726
----------------------------
Number of entries returned 1
----------------------------
# ipa trust-show tbad.example.com
   Realm name: tbad.example.com
   Domain NetBIOS name: TBAD
   Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726

# ipa trustdomain-find tbad.example.com
   Domain name: child.tbad.example.com
   Domain NetBIOS name: CHILD
   Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075

   Domain name: tbad.example.com
   Domain NetBIOS name: TBAD
   Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726
----------------------------
Number of entries returned 2
----------------------------

The only bigger change I did was to filter trust root domains by
ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not
available to everyone.

Martin


The patch looks good to me, but I think Alexander is better qualified to review it.

--
PetrĀ³

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

Reply via email to