Hi, Jakub,

Thank you for taking the time to reply to my email.  It is nice to know that 
short names will be possible in 7.3.  Unfortunately this will not address the 
problem we are trying to resolve; to make a long story short we are working 
with a proprietary system called Isilon OneFS (a scale out NAS platform made by 
EMC); we are aggregating records from disparate authenticate sources into a 
single identity (the mapping engine is proprietary).   The aggregation logic 
implemented matches based on username.  So, we need the user (and group) names 
in their short representation served up via either LDAP or NIS, not just via 
SSSD.

It sounds like with 7.3 it might be possible to do this if we implement a NIS 
server on a client running an SSSD client with id_provider=ipa.

One of the things we are struggling with is enumerating every object (of either 
user or group class) of a foreign domain via querying IPA’s LDAP server.  It is 
possible to explicitly query entries from remote domain from my IPA instance 
via LDAP by querying for username@f.q.d.n<mailto:username@f.q.d.n>, but it does 
not seem possible to query for all user objects in a foreign domain by doing 
something such as a wildcard search.  If it is possible to enumerate all 
objects from a specific class from a foreign domain (i.e. force the generation 
of anchor records), we be interested in the methodology behind this.

Thank you again for all of your help.

Best,

Dan Sullivan

On Apr 29, 2016, at 2:22 AM, Jakub Hrozek 
<jhro...@redhat.com<mailto:jhro...@redhat.com>> wrote:

On Thu, Apr 28, 2016 at 06:31:20PM +0000, Sullivan, Daniel [AAA] wrote:
Jakub,

Thank you for your reply.  I did not know that the compat tree was
populated from sssd; Do you have any experience and or recommendation on
using the full_name_format variable of sssd.conf to manipulate how cn’s are
populated in anchor records?  Basically I’m interested in trying to get
IPA to provision anchor records for a trusted domain without the @f.d.q.n
appended to usernames.  It seems like having a custom full_name_format
(sssd.conf) possibly in conjunction with default_domain_suffix (sssd.conf)
might achieve this (have already done some internal testing with partial
results, running into some issues but interested in yours and the groups
opinion on the viability of this).

It's not possible at the moment to change the output format of the sssd
on the server or the format of the entries in the compat tree. Several
pieces of the stack (including the extdom plugin that serves requests to
the sssd clients) rely on the name being qualified at least on the
server side to function properly.

What should be possible starting with 7.3 is to have the shortnames
in the output of SSSD clients with id_provider=ipa.

But I'm not sure legacy clients would work either with shortnames
because with the legacy clients, we typically treat the whole
qualified string as a "name":

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[sssd]
services = nss, pam
config_file_version = 2
domains = default
re_expression = (?P<name>.+) <-------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

the re_expression tells sssd that the whole input string, qualified or not
is a "name", there is no separate IPA and AD domain in these setups. This
is because with the legacy clients, those clients must use the "ldap"
id_provider pointed to the compat tree and the 'ldap' provider, unlike the
'ipa' or 'ad' providers has no notion of trusted domains internally.

So if you want to use shortnames on the output, I think the best bet is
to wait for sssd-1.14 (coming in RHEL-7.3) with the ipa provider.


********************************************************************************
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