You don't have to add them as an administrator for login to work, just sudo. Will send one over in a second.
On Tue, Jun 21, 2016 at 12:11 PM, Cal Sawyer <[email protected]> wrote: > <hits brakes, swerves> ... "have to add the user as an administrator on > the local machine"? That's pretty intriguing, but not great security-wise, > unfortunately. Not a big deal at the moment, though > > ok, just made my user account an admin but it's still dragging on login. > > My IPA setup is the same: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > Any chance i could get a denatured plist from you offline, Joe? > > cheers > > 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 16:07, Joe DiTommasso wrote: > > 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 <[email protected]> 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 < <[email protected]> >> [email protected]> 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 <[email protected]> >>> <[email protected]> >>> To: Nicola Canepa <[email protected]> <[email protected]> >>> Cc: "[email protected]" <[email protected]> >>> <[email protected]> <[email protected]>, Cal Sawyer >>> <[email protected]> <[email protected]> >>> >>> 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 >>> <[email protected]><[email protected]> <[email protected]>: >>> >>> 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 <[email protected]> >>> <[email protected]>[email protected]" >>> >>> -- john >>> >>> >>> 2015-12-20 15:09 GMT+01:00 Cal Sawyer <[email protected]> >>> <[email protected]>: >>> >>> >>> 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
