[Freeipa-users] Default Trust View --> not able to resolve AD user on clients
Hi, We only used the default trust view. Recently a colleague added another ID View. After that when adding a lot of new users from AD, with overrides in the Default Trust View we were not able to resolve the new users (id: ‘xx’: no such user) on IPA clients. No problem on the IPA servers (at first sight) After searching a lot on different parameters (pam_id_timeout etc)and clearing caches we found that the problem disappeared when adding users to a new ID View and removing them from the Default Trust View. Running latest on RHEL 7.x (VERSION: 4.6.8, API_VERSION: 2.237) Any similar reports? Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] UPPERCASE usernames
Hi , Current IPA environment is using lowercase usernames. But we also have a LDAP environment in which usernames are in UPPERCASE. This is used for "some" krb tickets possibilities. Imagine we add users to the Default Trust View and adapt login to UPPERCASE. Can we expect some troubles or nuisances (think SSO, SSH, Kerberos...) I remember very good some installers don't like adding local users on installation with a login in uppercase. We can use other override(s), but maybe this is not feasible from a user management perspective. Especially regarding the normal typical POSIX way, which was also described in the username restrictions thread (10/2018) [1] https://paulgorman.org/technical/presentations/linux_username_conventions.pdf Sincerely, Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Windows clients and domain_realm mappings
On Fri, Oct 18, 2019 at 8:26 AM Alexander Bokovoy wrote: > On pe, 18 loka 2019, Pieter Baele wrote: > >All Windows clients are properly enrolled into the AD domain. > > > >We can't use two-way trust because of reasons you explained here before. A > >one-way external trust is used. All perfectly established and working, but > >somehow windows clients don't follow the topology. > Ok, so this is the key information you did not say in the original > email. ;) > Yeah. Sorry :-) > External trust only works for the domain you trust directly, not for > > > Perfect explanation. > > > >By adding a domain_realm mapping to a windows client, also describe on > >FreeIPA-users before, the routing problem is solved. But I (and especially > >the AD admins ;-) ) would prefer to solve the underlying issue. > Don't use external trust, use forest trust. The effect you see is a > design limit of external trust. > The AD admins don't trust IdM ;-) Their Microsoft consultant/expert also thinks we are doing dangerous things. Conclusion: - they either have to choose between applying the GPO - or forest trust. I understand completely, because there was a precedent because of some old interconnection between Samba as PDC and the AD domain. This required the AD domain to stay on an old functional level. Same thing with enctypes in Kerberos tickets > > >Thanks a lot, it is quite hard to find experts (with knowledge of both > >LDAP, AD and different Kerberos implementations)(we are reaching out to > RH) > If you are reaching out to Red Hat support, your request will eventually > get to my hands. > I know. Sometimes difficult when there is other support people in-between Thanks a lot, this made things very very clear ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Windows clients and domain_realm mappings
All Windows clients are properly enrolled into the AD domain. We can't use two-way trust because of reasons you explained here before. A one-way external trust is used. All perfectly established and working, but somehow windows clients don't follow the topology. By adding a domain_realm mapping to a windows client, also describe on FreeIPA-users before, the routing problem is solved. But I (and especially the AD admins ;-) ) would prefer to solve the underlying issue. Thanks a lot, it is quite hard to find experts (with knowledge of both LDAP, AD and different Kerberos implementations)(we are reaching out to RH) Sincerely Pieter On Wed, 16 Oct 2019, 10:08 Alexander Bokovoy, wrote: > On ke, 16 loka 2019, Pieter Baele via FreeIPA-users wrote: > >The only open issue we have with IPA is Windows clients not being directed > >to the Kerberos servers of the IPA realm. > > I think there is lack of a context here in your question. > > For forest trust to Active Directory, all cross-realm routing is being > done by AD DCs according to the topology associated with the trusted > domain object. FreeIPA pushes out that information when trust is created > and AD DCs follow it. We take all domains from the list maintained by > realmdomains command. > > So there is no need to have anything additional there. Windows clients > will properly use SRV DNS records from primary IPA DNS domain. I think > there is one missing DNS record right now that was found recently in > FreeIPA 4.8.1: https://bugzilla.redhat.com/show_bug.cgi?id=1711958 > > However, this has nothing to do with Kerberos. > > We do not support non-enrolled Windows configurations, so if by 'Windows > clients' you mean exactly that, sorry, nothing can be done. > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Windows clients and domain_realm mappings
The only open issue we have with IPA is Windows clients not being directed to the Kerberos servers of the IPA realm. We can solve this issue using domain_realm registry keys as mentioned on the mailing list before. But is there any different method to accomplish this? As far as I know/read, Windows clients only use SRV DNS records (and can fail back to NetBIOS-based discovery) to locate domain services, not TXT records. As IETF Kerberos Clarification drafts recommend against using (then) unsecured DNS for domain_realm mappings. So TXT DNS domain_realm mappings are also not an option. Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] IPA integration with AD - trust issues and controversy
Hi, We use an IPA domain for a large part of our internal servers. Our first one-way trust implementation was not properly working because of routing issues. Two-way trust in our environment is not possible, because normal users are limited. (we can resolve 'system/service' accounts without those limitations) After finding out about this limitation, we did again configure one-way trust. This time, we found about the registry / GPO solution to direct windows clients to the IPA KDC's. ( https://gpo.wiki/wiki/Kerberos.admx:Computer_Configuration#Define_host_name-to-Kerberos_realm_mappings ) And all is working properly... Last week we received a request from an external company that wants AD integration. They will manage their own set of RHEL servers for a specific project. I proposed they can use the IDM domain for feature-full integration with the AD domain. But there is some discussion going on our AD architect(s) calls the IPA integration with AD lacking. Their opinion is that windows clients should discover automatically when they need a IPA KDC Also, they find it a severe issue that everything is hidden after one SID (which is given permissions with the correct search scope) As such they can' t see/discover anything in the IPA domain (logically...) So the Windows / AD guys propose a direct integration using a keytab - without thinking about the requirements, and comparing with network devices or appliances I am not talking about realmd. What is the up-to-date opinion on SSSD realmd integration versus IDM integration? Or other options? What will the external company be losing in features? And which has most risks? But most of all: what can we do to make IPA domain<-> AD domain integration better? Sincerely, Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] kinit: KDC can't fulfill requested option while renewing credentials - which approach?
I tried various approached to get Renewable tickets : modifying the kdc modifying krb5.conf using kadmin.local on every replica to modify the principal; which is not working - as designed (?)- in IPA What should I do to get a ticket with the correct R flag from IPA ? I don't think this is SSSD related (the service needing the renewable ticket this way is Apache Storm) Thanks a lot! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA PPC64LE builds
RHEL is indeed available for Power 8 and Power 9. But FreeIPA server is not, only the clients / sssd :-( On Mon, Nov 12, 2018 at 7:14 PM Rob Crittenden wrote: > Pieter Baele via FreeIPA-users wrote: > > Seriously? I could not find them in our internal satellite 6 install and > > support was going more into the subject of the IBM acquisition then > > technical stuff > > I saw it on access.redhat.com -> Downloads, Red Hat Enterprise Linux for > Power, little endian. > > rob > > > > > On Mon, 12 Nov 2018, 17:55 Rob Crittenden, > <mailto:rcrit...@redhat.com>> wrote: > > > > Pieter Baele via FreeIPA-users wrote: > > > Anyone an idea what the timeline/roadmap is for FreeIPA ipa-server > > > PPC64LE build for Centos 7 (or RH IDM on RHEL 7/8) > > > > > > I only see some packages for PowerPC on Fedora and Ubuntu > > > > ppc64le RHEL builds are available for RHEL 7 today (and IdM is part > of > > RHEL). > > > > You'll need to ask CentOS for what they build on/support. > > > > rob > > > > > > > > ___ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to > freeipa-users-le...@lists.fedorahosted.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > > > > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: FreeIPA PPC64LE builds
Seriously? I could not find them in our internal satellite 6 install and support was going more into the subject of the IBM acquisition then technical stuff On Mon, 12 Nov 2018, 17:55 Rob Crittenden, wrote: > Pieter Baele via FreeIPA-users wrote: > > Anyone an idea what the timeline/roadmap is for FreeIPA ipa-server > > PPC64LE build for Centos 7 (or RH IDM on RHEL 7/8) > > > > I only see some packages for PowerPC on Fedora and Ubuntu > > ppc64le RHEL builds are available for RHEL 7 today (and IdM is part of > RHEL). > > You'll need to ask CentOS for what they build on/support. > > rob > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] FreeIPA PPC64LE builds
Anyone an idea what the timeline/roadmap is for FreeIPA ipa-server PPC64LE build for Centos 7 (or RH IDM on RHEL 7/8) I only see some packages for PowerPC on Fedora and Ubuntu ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: shortname in trusted ad domain
Jakub, Alexander, I really appreciate your quick responses. This is about the SAS Viya product. I had to find out myself why their software doesn't want to create new session(s) from their 'CAS Session controller' It's only a guess, because I don't have access to the source obviously ;-) But they rely on the PAM stack and messages like “User has name @ on machine …” point in a certain direction I always thought that using IPA for our Big Data platforms would be nice, because of the Kerberos features. But in the end I had to configure most services to go to AD directly only because of the FQDN issues and the way the trust iw working IPA goes a long way easing the maintenance of POSIX, HBAC, Kerberos on RHEL systems but still AuthZ/AuthN is a tedious subject if you also have to integrate it with the software itself and legacy systems such as AIX (!) Sorry for my rant, but IDM is only a part of my job, the Hortonworks platform takes preference above the OS which has to be stable ;-) Still I want Kerberos SSO for some services, but is that even possible for windows clients (browser) and keytabs generated in IDM the trust only goes one way? @Jakub: not planning to use full_name_format on IDM servers, only on the (SAS Viya) CAS Worker Nodes (if this is the problem) Somehow I can no longer login directly using my AD user (which has an override in IPA) - once the db/mc/cache is cleared. Sep 6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x user=y Sep 6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth): received for user x: 6 (Permission denied) Sep 6 09:54:27 iictyibcls012 sshd[30881]: error: PAM: Authentication failure for x from hostx Sep 6 09:54:27 iictyibcls012 sshd[30881]: Postponed keyboard-interactive for xfrom 10.249. @Alexander: I know the limitations and the impact / slow-down. Only one domain will be trusted - ever. Sincerely Pieter On Thu, Sep 6, 2018 at 9:39 AM Alexander Bokovoy wrote: > On to, 06 syys 2018, Pieter Baele wrote: > >That was not an answer meant for me :-) - it dates from 13 may upon > >release of the sssd release supporting those configurations. > >And it doesn't solve the problem. > >I also opende a ticket with RH Support (we tend to pay a lot of money for > >that directly to developer is sometimes faster, isn't it?) > If you are using trust to AD with multiple domains, you are having users > which would be conflicting in non-FQDN format. Each AD domain has the > same set of predefined users (Administrator, group Administrators, etc), > so these ones will already be conflicting to each other. > > As result, in general there is no way to make it working for non-FQDN > users in case of a trust to AD. Recent SSSD and IPA allow you to define > an order of domains to look up unqualified inputs against. A side-effect > is that such lookups might become slower and are prone to conflicts > where a first one from a list of the domains would take over the > response. > > You need to explain a bit in more detail what this PAM-based > application is and what it is supposed to do. If the application does > getpwuid()-like requests it would get back qualified user name anyway. > SSSD in a configuration where an order of domains to query is defined > can accept non-qualified user/group names, indeed, but if an application is > using a UID to name or GID to name resolution it might be confused with > the FQDN response. > > Finally, on IPA masters do not reconfigure SSSD to output non-FQDN > names. This breaks badly compat tree and if you'd use legacy clients > with trust to AD, there is no way to fix that. > > > > >Thx for any advice > > > > > > > > > > > >On Thu, Sep 6, 2018 at 9:23 AM Alexander Bokovoy > >wrote: > > > >> On to, 06 syys 2018, Pieter Baele via FreeIPA-users wrote: > >> >Hi, > >> > > >> >I've one more application that doesn't behave very properly with FQDN > >> users. > >> >For LDAP, this is no longer a problem as we use AD directly for > >> >applications now. > >> >But this application uses PAM, so somehow I do need to present it a > >> >shortname as described in > >> > > >> > https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.html#test-short-names-for-trusted-domains > >> >and https://docs.pagure.org/sssd.sssd/design_pages/shortnames.html > >> > > >> >Adding use_fully_qualified_names = False indeed results in the > possibility > >> >of using instead of @ > >> >But the returned/displayed values are still @ or > >> >@ > >> > > >> >I could resolve t
[Freeipa-users] Re: shortname in trusted ad domain
That was not an answer meant for me :-) - it dates from 13 may upon release of the sssd release supporting those configurations. And it doesn't solve the problem. I also opende a ticket with RH Support (we tend to pay a lot of money for that directly to developer is sometimes faster, isn't it?) Thx for any advice On Thu, Sep 6, 2018 at 9:23 AM Alexander Bokovoy wrote: > On to, 06 syys 2018, Pieter Baele via FreeIPA-users wrote: > >Hi, > > > >I've one more application that doesn't behave very properly with FQDN > users. > >For LDAP, this is no longer a problem as we use AD directly for > >applications now. > >But this application uses PAM, so somehow I do need to present it a > >shortname as described in > > > https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.html#test-short-names-for-trusted-domains > >and https://docs.pagure.org/sssd.sssd/design_pages/shortnames.html > > > >Adding use_fully_qualified_names = False indeed results in the possibility > >of using instead of @ > >But the returned/displayed values are still @ or > >@ > > > >I could resolve that with full_name_format = %1$s, but this breaks logon > >for trusted AD users > > > >Which is confirmed on the sssd mailing by Jakub Hrozek > >"Keep in mind that by default, the names will still come back qualified > >from the child domains because that’s the only way to distinguish users > >from different domains during a multi-step authentication process (e.g. > >application receives a name to authenticate as, then calls getpwnam on > that > >input and uses the output of getpwnam from then on..). You /can/ tune the > >full_name_format to only include the user name, but please be aware of the > >consequences." > > > >Or is there a configuration which is a solution for this issue? > Jakub gave you the answer. The client side is all in SSSD control. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] shortname in trusted ad domain
Hi, I've one more application that doesn't behave very properly with FQDN users. For LDAP, this is no longer a problem as we use AD directly for applications now. But this application uses PAM, so somehow I do need to present it a shortname as described in https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.html#test-short-names-for-trusted-domains and https://docs.pagure.org/sssd.sssd/design_pages/shortnames.html Adding use_fully_qualified_names = False indeed results in the possibility of using instead of @ But the returned/displayed values are still @ or @ I could resolve that with full_name_format = %1$s, but this breaks logon for trusted AD users Which is confirmed on the sssd mailing by Jakub Hrozek "Keep in mind that by default, the names will still come back qualified from the child domains because that’s the only way to distinguish users from different domains during a multi-step authentication process (e.g. application receives a name to authenticate as, then calls getpwnam on that input and uses the output of getpwnam from then on..). You /can/ tune the full_name_format to only include the user name, but please be aware of the consequences." Or is there a configuration which is a solution for this issue? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Passync AD *and* trust?
Hi, Would it somehow be possible to - partially - sync AD users (max 200) with IPA while still using a trust with the same domain? Logically this sounds like a bad idea, but my colleagues would really really like to use IPA also for AIX. The biggest limitation is that the AIX client doesn't work well with @ in IPA compat. What would possible work-arounds be to make use of IPA on AIX...? A custom virtual LDAP which strips the @ part, but keeps all other LDAP data the same? Using some commercial offering? Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/VQPAFC4LTHCUBVKGOYFMSN6OEYXR3DCL/
[Freeipa-users] Re: fqdn - domainsuffix in compat (AIX)
Ok, thanks for the clarification. So there is *no* possibility to serve AIX completely... There goes the use-case for our Unix admins - np ;-) On Wed, Jul 25, 2018 at 1:56 PM Alexander Bokovoy wrote: > On ke, 25 heinä 2018, Pieter Baele via FreeIPA-users wrote: > >Is it somehow possible to have the uid field > >in cn=users,cn=compat,dc=accnix,dc=infrabel,dc=be without the domain > >extension? > No, it is *not* possible. The whole idea of compat tree is to trigger > lookups only when @ad.domain is present, otherwise it will be very > inefficient in terms of performance. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/LU36P3DXYPEAUHF64FSLIULJVQPE6W5F/
[Freeipa-users] fqdn - domainsuffix in compat (AIX)
Is it somehow possible to have the uid field in cn=users,cn=compat,dc=accnix,dc=infrabel,dc=be without the domain extension? It is causing problems for AD users using an IPA-AD trust This problem was also discussed in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/H6LLSWTXJ3KGERZ6DZFCA4KNQMGLEEOH/ Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OVKDNHYQSMAEEXPTXTQ7ITS6OMFFZ2TF/
[Freeipa-users] Re: AD user shown id command but visible for ldapsearch
Thanks a lot Alexander Strange, I am almost sure I got no results earlier if I used uid=** searches Users are perfectly found now both fully-qualified and wither other queries. Honestly, it's a bit a missing feature (for my use cases!) that RFC2307bis draft 02 presentation is missing for AD users, on the other side it is a very nice accomplishment that both RFC2307 in compat and RFC2307bis in cn=accounts are available in FreeIPA. Its a perfect platform for Linux and suitable for UnixBecause IMO LDAP always has been a bit too complicated for system auth ;-) $ ldapsearch -Y GSSAPI -b cn=compat,dc=accnix,dc=infrabel,dc=be '(&(objectClass=posixAccount)(uid=*mcj*))' SASL/GSSAPI authentication started SASL username: ad...@accnix.infrabel.be SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=posixAccount)(uid=*mcj*)) # requesting: ALL # # mcj7...@accmsnet.railb.be, users, compat, accnix.infrabel.be dn: uid=mcj7...@accmsnet.railb.be ,cn=users,cn=compat,dc=accnix,dc=infrabel,dc= be objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos: x cn: x uidNumber: x gidNumber: x homeDirectory: /home/Accmsnet.railb.be/mcj7700 ipaAnchorUUID:: x uid: mcj7...@accmsnet.railb.be Thx a lot! -- Pieter On Wed, Jul 4, 2018 at 7:22 AM Alexander Bokovoy wrote: > On ke, 04 heinä 2018, Pieter Baele via FreeIPA-users wrote: > >Hi, > > > >On a test FreeIPA environment (4.5.0-22), a user is shown using the id > >command, so ID Override is working as well. > >id x...@accmsnet.railb.be > >uid=8028(x...@accmsnet.railb.be) gid=4030(ucc) > >groups=4030(ucc),702800513(domain us...@accmsnet.railb.be > >),131849(ad_users) > > > >However this particular (AD) user is not shown using an ldapsearch in the > >compat > >ldapsearch -Y GSSAPI -b cn=compat,dc=accnix,dc=infrabel,dc=be > >'(&(objectClass=posixAccount)(uid=))' > > > ># extended LDIF > ># > ># LDAPv3 > ># base with scope subtree > ># filter: (&(objectClass=posixAccount)(uid=mcj7700)) > Here uid is non-fully qualified. A trigger in the compat tree plugin is > built around using fully qualified user names for AD users, e.g. > (uid=mcj...@accmsnet.railb.be). > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IJGUGRQN5UF3EHIJCNR4IPH3CT7T3RIW/
[Freeipa-users] AIX 7.x with sudo, netgroups, LDAP and Kerberos
I have currently been assisting an AIX colleague to use IPA as authentication/authz provider for AIX systems. That way we are moving to a common platform We have found some examples on the web (AIX 5.x, AIX 6); information here and there - but for the moment we still have a few issues. The proprietary AIX schema extensions would be a nice to have, but are not required (as I have read in earlier posts) Has anyone seen a complete working example for a AIX client configuration for FreeIPA? Once we have found everything; I'll try to share the information. -- PieterB ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/YC4HJU7CBR6DX2LGPQZSEZN5QKJV6DC3/
[Freeipa-users] AD user shown id command but visible for ldapsearch
Hi, On a test FreeIPA environment (4.5.0-22), a user is shown using the id command, so ID Override is working as well. id x...@accmsnet.railb.be uid=8028(x...@accmsnet.railb.be) gid=4030(ucc) groups=4030(ucc),702800513(domain us...@accmsnet.railb.be ),131849(ad_users) However this particular (AD) user is not shown using an ldapsearch in the compat ldapsearch -Y GSSAPI -b cn=compat,dc=accnix,dc=infrabel,dc=be '(&(objectClass=posixAccount)(uid=))' # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=posixAccount)(uid=mcj7700)) # requesting: ALL # # search result search: 4 result: 0 Success Any idea? This is not happening in our production environment. I cleared caches, did enable slapi-compat, and even tried adding the resolution by an ldif to be sure I did also re-run ipa-adtrust-install I really don't understand why the AD users are not visible in LDAP Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/3W4QMCIGIPDUY3V65M2Q723AF3FWRAFP/
[Freeipa-users] Re: (no subject)
Hi, I was indeed thinking on using OAuth for the application (SAS Viya). Standard platform: ADFS. Adding Keycloak is do-able, but currently not in scope. We are a small (sub)team and how much is manage-able? ;) The applicaton - SAS Viya - always needs LDAP as identity store - in combination with Kerberos (& IWA), OAuth, SAML, plain LDAP or PAM. I find the implementation of their LDAP client a bit lacking (only 1 LDAP host, no referral setting, no starttls) One of the business requirements is "seamless" authentication and I was hoping we could use SPNEGO. Our Hadoop (and related servers such as SAS Viya) are all placed in a separate IPA domain, and we have a trust with AD. So this works for a firefox browser configured to use MIT Kerberos against IPA and the pure IPA users. But me idealistic scenario of using end-users from AD on that SAS Viya platform is currently leading to nowhere. Do you think it would be possible using ADFS Oauth? And AD LDAP as identity lookup store (if the problems are fixed) with all servers in the IPA domain? If not, what about Keycloak integrated with IPA -->we still would have the problem with AD user lookup then. Would be easier if the product uses SSSD/PAM as identity store as well somehow... Sincerely Pieter On Mon, Jul 2, 2018 at 2:15 PM Alexander Bokovoy wrote: > On ma, 02 heinä 2018, Pieter Baele via FreeIPA-users wrote: > > Hi, > > > >We have an application (Spring LDAP backend) that uses ketyabs in the IPA > >domain for SSO auth. > >No problems at all for internal FreeIPA users after they have a valid > >ticket (using MIT Kerberos for Windows) and a correctly configured > browser. > > > >An AD user is never present in IPA itself as an inetOrgPerson objectclass > >(correct?). > >So because AD users are only present in the compat tree after adding them > >the "Default Trust View" , configuration of the application is a problem. > >Because of the schema, I can only use posixAccount and membership is using > >memberUid / RFC2307 (correct again?) > Correct. > > >The absence of inetOrgPerson information (and memberOf) in the compat > view, > >gives me difficulties connecting this component to FreeIPA > memberOf is part of RFC2307bis, so out of scope for compat tree. > > > >Anyone experience with connecting Spring to IPA - AND - being able to use > >AD users? > If you are able to switch to a different authentication provider, I'd > rather take a different approach: use OpenID Connect/OAuth instead. > You'd connect your Spring application to an IdP like Keycloak and then > connect Keycloak to IPA. This would work for any complex setup because > authentication and identity retrieval at Keycloak side would be handled > by SSSD. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/DRJFBRVLGNZ7JUI6KJ6OJ3TEF533BQ4S/
[Freeipa-users] Spring LDAP connection to FreeIPA for AD trust users
Hi, We have an application (Spring LDAP backend) that uses ketyabs in the IPA domain for SSO auth. No problems at all for internal FreeIPA users after they have a valid ticket (using MIT Kerberos for Windows) and a correctly configured browser. An AD user is never present in IPA itself as an inetOrgPerson objectclass (correct?). So because AD users are only present in the compat tree after adding them the "Default Trust View" , configuration of the application is a problem. Because of the schema, I can only use posixAccount and membership is using memberUid / RFC2307 (correct again?) The absence of inetOrgPerson information (and memberOf) in the compat view, gives me difficulties connecting this component to FreeIPA Anyone experience with connecting Spring to IPA - AND - being able to use AD users? Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/B3ERHDPEGFFNFBHA6OKXRT2QX7V2XRHC/
[Freeipa-users] (no subject)
Hi, We have an application (Spring LDAP backend) that uses ketyabs in the IPA domain for SSO auth. No problems at all for internal FreeIPA users after they have a valid ticket (using MIT Kerberos for Windows) and a correctly configured browser. An AD user is never present in IPA itself as an inetOrgPerson objectclass (correct?). So because AD users are only present in the compat tree after adding them the "Default Trust View" , configuration of the application is a problem. Because of the schema, I can only use posixAccount and membership is using memberUid / RFC2307 (correct again?) The absence of inetOrgPerson information (and memberOf) in the compat view, gives me difficulties connecting this component to FreeIPA Anyone experience with connecting Spring to IPA - AND - being able to use AD users? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/WYH2OEF7CGQCM2GFAPXRB436MXFMVMX2/
[Freeipa-users] Re: Knox and IPA integration
https://github.com/abajwa-hw/security-workshops/blob/master/Setup-knox-23.md Adapts as necessary On Mon, Nov 13, 2017 at 4:28 PM, Kat via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Curious if anyone has done any configuration in using Apache Knox and > integrating into IPA for Kerberos auth? > > thanks > > K > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] trying to retrieve CA cert via LDAP .... stuck
Hi, I've a weird problem with 2 hosts on ipa-client-install registration. All my servers are using a 99% alike kickstart profile. 8 hosts did their registration almost immediately (after submit of admin) But on 2 servers I am stuck with: stderr= trying to retrieve CA cert via LDAP from Any idea what the reason could be? I checked: DNS, firewall But all verifications and discovery before this step are successful. It's only possible I did a ipa-client-uninstall on those hosts before. (not 100% sure) Sincerely Pieter ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
