On 4/18/16, 10:06 AM, "Jakub Hrozek" <jhro...@redhat.com> wrote:

>On Mon, Apr 18, 2016 at 01:47:04PM +0000, Brook, Andy [CRI] wrote:
>> 
>> On 4/18/16, 5:03 AM, "freeipa-users-boun...@redhat.com on behalf of Jakub 
>> Hrozek" <freeipa-users-boun...@redhat.com on behalf of jhro...@redhat.com> 
>> wrote:
>> 
>> >On Fri, Apr 15, 2016 at 08:01:06PM +0000, Brook, Andy [CRI] wrote:
>> >> We’re trying to setup FreeIPA to be a good provider of UIDs and GIDs for 
>> >> our mostly RHEL systems. Overall, that works great. The issue I’m running 
>> >> into is that we need to have the same consistent UIDs and GIDs for our 
>> >> Isilon system which serves up both CIFS and NFS. Each user of the Isilon 
>> >> needs to have a UID so that the files are owned properly. The Isilon has 
>> >> a way of getting information from both Active Directory and an associated 
>> >> LDAP server. It gets its list of users and groups from AD, a list of 
>> >> users, UIDs, groups and GIDs from LDAP, and combine accounts that are the 
>> >> same. i.e. ADTEST.LOCAL\abrook and abrook from LDAP will the same user. 
>> >> However, FreeIPA will show abrook(as it sees through the Trust 
>> >> relationship with ADTEST.LOCAL) as 
>> >> abrook@adtest.local<mailto:abrook@adtest.local> instead of abrook, so the 
>> >> Isilon will see them as distinct accounts and won’t merge the information 
>> >> in them. I can’t, as far as I can tell right now, tell the Isilon to see 
>> >> users with @adtest.local as the same user without the domain. I can tell 
>> >> the Isilon to look at a different LDAP attribute as its username, but 
>> >> there is no attribute that has only the username.
>> >> 
>> >> I noticed in the documentation that if I were to do a sync with Active 
>> >> Directory (which isn’t something I want to do), I would get the 
>> >> ntDomainUserID attribute that is the same as the samAccountName. This 
>> >> doesn’t happen with a trust. Is there a way to get that in place with a 
>> >> custom attribute or pull more LDAP attributes from AD?
>> >> 
>> >> Has anyone else run into a situation like this? If so, were you able to 
>> >> rectify that? If so, how?
>> >> 
>> >> We have a ticket open with EMC for the Isilon as well, but want to make 
>> >> sure we’re coming at this from all the angles we can.
>> >
>> >I'm sorry, but currently overriding the attribute names for AD trusted
>> >domains is not possible. We are working to make it possible for the next
>> >version, but it's a bit of a stretch goal already, so chances it won't
>> >be ready only for the version after the next one.
>> >
>> >What might perhaps help you is that starting with upstream SSSD 1.14
>> >(upstream 7.3), it should be possible to configure SSSD to only print
>> >the shortname and not qualify the users in trusted domains.
>> >
>> 
>> Thank you. In your suggestion, are you talking about SSSD on the IPA
>> Servers? My understanding of how SSSD on the IPA servers interacts with
>> the servers that talk to them is pretty limited. If I upgrade SSSD on
>> these servers, I might be able to get LDAP to not print the qualifying
>> domain during ldapsearch?
>
>Depends on how you want to query the information, whether with "getent
>passwd $user" or ldapsearch. SSSD itself doesn't provide any data to
>ldapsearch, but provides NSS, PAM and D-Bus interfaces.
>
>And you'd have to upgrade SSSD on both clients and servers.

For the issue that I’m having, it’s not actually something with an SSSD client. 
The Isilon isn’t a server that SSSD is or can be installed on. It’s a storage 
appliance that is provided from EMC. It can, however, search LDAP for accounts 
and groups as well as connect to Active Directory. 

>
>> 
>> I’m not really asking about overriding attribute names, but rather
>> adding a new attribute that only has the shortname. Is there a way to
>> do that may through a custom NIS mapping or something like that? Maybe
>> a dynamic schema extension? I’ve tried reading through extending the
>> schema, but am currently confused as to how to go about it.
>
>It sounds like the new attribute would be added on the AD side, but at
>the moment, SSSD's attribute map for the trusted domains is hardcoded.
>
>The only way would be to query the attribute through our d-bus API.

Okay, so it’s looking like there’s no good way to do what I’m looking for. 
Essentially the issue is that the Isilon can’t quantify the domain that the 
user is logging in with, i.e. it can’t turn LDAPTEST.LOCAL\user into 
user@ldaptest.local to know that what it’s seeing from LDAP is the same as what 
it got from its active directory login. 

We’re working on another way to do what we need, but still use IPA server. Can 
you answer when IPA provisions a UID for a user in the trusted domain? If I 
were to do a ‘ldapsearch cn=users,cn=compat,dc=tst,dc=ipaexample,dc=com’ (where 
tst.ipaexample.com trusts ldaptest.local) would I see all the ldaptest.local 
users/groups with their associated generated UIDs/GIDs? Essentially, if we can 
get a list of users, groups and their associated UIDs/GIDs, we can create the 
correct association within the Isilon. We just need to make sure we can get the 
correct UIDs before a user has ever touched the IPA environment. 

Andy Brook
Sr. Systems Administrator | Center for Research Informatics | University of 
Chicago
T: 773-834-0458 | http://cri.uchicago.edu




********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to