[Freeipa-users] OS X Yosemite unable to authenticate

Tue Jun 21 15:07:37 UTC 2016

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 at 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 <cal-s at 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 <cal-s at 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.obaterspok at gmail.com> <john.obaterspok at gmail.com>
>> To: Nicola Canepa <canepa.n at mmfg.it> <canepa.n at mmfg.it>
>> Cc: "freeipa-users at redhat.com" <freeipa-users at redhat.com> <freeipa-users at redhat.com> <freeipa-users at redhat.com>,	Cal Sawyer
>> 	<cal-s at blue-bolt.com> <cal-s at 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
>> <canepa.n at mmfg.it><canepa.n at mmfg.it> <canepa.n at 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 at REALM.suffix> <user at REALM.suffix>user at REALM.suffix"
>>
>> -- john
>>
>>
>> 2015-12-20 15:09 GMT+01:00 Cal Sawyer <cal-s at blue-bolt.com> <cal-s at 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160621/3c0e04d3/attachment.htm>