[Freeipa-users] OS X Yosemite unable to authenticate

Tue Jun 21 16:40:02 UTC 2016

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 <cal-s at blue-bolt.com> 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 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>
>> 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/15c0ab68/attachment.htm>