No fiddling that I remember. Basically got the setup working once and then have been pushing out plist files to all new installs. Graphical login works, as does sudo, sort of-still have to add the user as an administrator on the local machine, but then their kerberos password works for authentication. Running up-to-date-ish IPA 4 on CentOS 7.
jdito@sum-freeipa-01:~$ rpm -qa | grep ipa *ipa*-python-4.2.0-15.0.1.el7.centos.6.1.x86_64 lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64 *ipa*-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 python-in*ipa*rse-0.4-9.el7.noarch *ipa*-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64 sssd-*ipa*-1.13.0-40.el7_2.4.x86_64 *ipa*-client-4.2.0-15.0.1.el7.centos.6.1.x86_64 python-lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64 *ipa*-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64 Let me know what you'd like to see from my config. Thanks for the tip on the secondary groups-I already had that in there, but looking at it realized that I needed to point at the compat tree, because the regular one doesn't expose memberUID. On Tue, Jun 21, 2016 at 10:42 AM, Cal Sawyer <ca...@blue-bolt.com> wrote: > Wow, that's surprising, Joe. I'm also using the linsec recipe. Yours > required no fiddling? You can login straight off from the graphical > loginWindow? > > Yes, very interested in any help you can offer. Are you authenticating > against IPA 3 or 4, for sake of curiosity. > > BTW: you can get your secondary groups by: > > In Groups add attribute 'GroupMembership' mapped to 'memberUID' > > thanks! > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com > > On 21/06/16 15:07, Joe DiTommasso wrote: > > I've actually got a whole stack of El Capitan clients authenticating > against FreeIPA: > > mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType > Software: > > System Software Overview: > > System Version: OS X 10.11.5 (15F34) > Kernel Version: Darwin 15.5.0 > Boot Volume: Macintosh HD > Boot Mode: Normal > Computer Name: admin’s Mac mini > User Name: Joe DiTommasso (jdito) > Secure Virtual Memory: Enabled > System Integrity Protection: Enabled > Time since boot: 14 days 15:00 > > The Linsec guide worked for me. The only real issue is that it only sees > the user's primary group, and not supplemental groups. I'm not terribly > good with Macs, but happy to assist in troubleshooting. > > Joe > > On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer <ca...@blue-bolt.com> wrote: > >> As usual, apologies for any formatting issues due to extracting message >> threads out of digests ... >> >> Anyhow., i have determined where everything goes terribly wrong with OSX >> clients: OSX 10.10.3 ("out of the box" Yosemite) works fine using >> linsec.ca's guidance. However, the second you patch to 10.10.5 or >> upgrade to El Capitan (10.11.5), authentication fails absolutely in the >> ways described in earlier threads. Colleagues who i've spoken with who are >> trying to set up IPA at their facilities report the same problem and it's a >> total show-stopper. Interesting how all(?) of what is written on the topic >> of OSX and IPA dries up after 10.8, although we've seen in an earlier >> thread reports of 10.9 working. I've repeated this test a few times and >> the result is always the same. - 10.10.3 is the last OSX capable of >> authenticating against IPA using currently available knowledge. >> >> Running tcpdump on 10.10.3 and a 10.10.5 clients show very different >> authentication dialogues. I'm afraid, however, that i lack the skills to >> interpret where exactly the later OSX release is failing. I have my >> (unfounded) suspicions - that SASL binding for LDAP and kerberos are >> implicated. 10.10.3 certainly shows no kerberos transactions whereas 10.10.5 >> >> Re DNS: both client types resolve all SRV records hosted in IPA fine. I >> even went so far as setting up rudimentary ipv6 as there were some AAAA >> requests that were going unanswered and it thought it might related (not, >> as it turns out) >> >> So, would anyone on the IPA team be interested in looking at some packet >> captures? I'm completely up for working with you, providing whatever is >> needed and doing testing. It would be fantastic to restore IPA-based auth >> for newer OSX releases. >> >> best regards, >> >> - cal sawyer >> >> From: John Obaterspok <john.obaters...@gmail.com> <john.obaters...@gmail.com> >> To: Nicola Canepa <canep...@mmfg.it> <canep...@mmfg.it> >> Cc: "firstname.lastname@example.org" <email@example.com> >> <firstname.lastname@example.org> <email@example.com>, Cal Sawyer >> <ca...@blue-bolt.com> <ca...@blue-bolt.com> >> >> Hi, Are you only having problems to login to login to OSX with the IPA >> user now? If that is the case then check the DNS settings you are using and >> make sure the IPA server is listed first and that it has full name. Exactly >> the same problem occurred for me with the slow logins to OSX which was due >> to the DNS settings and that OSX only used short name of IPA server during >> login (if I logged in as local user I could ping and lookup hosts using >> short name) -- john 2015-12-21 17:49 GMT+01:00 Nicola Canepa >> <canep...@mmfg.it><canep...@mmfg.it> <canep...@mmfg.it>: >> >> I had to configure /etc/krb5.conf, and to avoid the requested reboot, I >> did a "dscacheutil -flushcache", both as the logged in user and as root. >> I tried enabling the anonymous bind and now also the directory browser >> (and all the login process) works as expected. >> >> Nicola >> >> Il 21/12/15 17:39, Cal Sawyer ha scritto: >> >> Thanks, John and Nicola >> >> Kerberos occurred to me as well late in the day yesterday. Happily (?), >> knit works fine simply specifying the user in question with no need to >> suffix with the kerberos realm >> >> I did find that my test user had an expired password, which i fixed on the >> IPA server. This was never flagged up under Linux, btw. It has not change >> anything, however, other than not prompting for password changes that never >> take effect. Funnily, it expired in the midst of testing - fun. >> >> I was mistaken when i said i was unable to log in - it turns out that it >> takes almost 10 minutes for a login from the frintend to complete - i just >> didn't wait long enough. 10 mins is of course unacceptable :) "su - user" >> and "login user" fail outright after rejecting accept any user's password >> >> DNS is fine and i can resolve ldap and kerberos SRV records from the Mac >> >> In line with Nicola's experience, i can browse groups and users in the >> Directory Editor and all attributes appear spot on. >> >> Besides modding /etc/pam.d/authorization, adding a corrected >> edu.mit.kerberos to /LibraryPreferences and setting up the directory >> perlinsec.ca, can anyone think of something i may have missed? It's a real >> shame that the documentation on this stops around 5 years ago. >> >> IPA devs: is there anything i should be on the lookout for in the dirsrv >> or krb5 logs on the IPA master? I've disabled the secondary to prevent >> replication from clouding the log events >> >> thanks, everyone >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com >> >> On 21/12/15 07:57, Nicola Canepa wrote: >> >> Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the >> opposite problem: kinit works fine, while I'm unable to see users with >> Directory Admin ((it always says it cant' connect, either with or without >> SSL) >> I disabled anonymous searches in 389-ds, by the way. >> >> Nicola >> >> Il 21/12/15 07:50, John Obaterspok ha scritto: >> >> Hi Cal, >> >> Does a kinit work from a terminal? Does it work if you use "kinit user" or >> just if you use "kinit <user@REALM.suffix> >> <user@REALM.suffix>user@REALM.suffix" >> >> -- john >> >> >> 2015-12-20 15:09 GMT+01:00 Cal Sawyer <ca...@blue-bolt.com> >> <ca...@blue-bolt.com>: >> >> >> Hi, all >> >> I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX >> 10.10.5 (Yosemite) client >> >> Using the excellent instructions >> at<http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server> >> >> <http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server>http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, >> I've populated the specified files, d/l'd the cert, am able to configure >> Users and Groups objects/attribs and browse both from within OSX's >> Directory Utility. ldapsearch similarly returns the expected results. >> >> In spite of this, i'm unable to authenticate as any IPA-LDAP user on this >> system >> >> dirsrv log on the ipa master shows no apparent errors - remote auth >> attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the >> truth, there so much stuff there and being rather inexperienced with LDAP >> diags i might easily be missing something in the details >> >> The linsec.ca instructions were written in the 10.7-10.8 era so >> something may have changed since. Having said that, we've had no problems >> authenticating against our existing OpenLDAP server (which IPA is slated to >> replace) right up to 10.10.5 with no zero to our Directory Utility setup. >> >> Hoping someone here has some contemporary experience with OSX and IPA and >> for whom this issue rings a bell? >> >> many thanks >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> 15-16 Margaret Street | London W1W 8RW >> +44 (0)20 7637 5575 <%2B44%20%280%2920%207637%205575> | www.blue-bolt.com >> >> >> >> -- >> 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 >> > > >
-- 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