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