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.
- cal sawyer
From: John Obaterspok<john.obaters...@gmail.com>
To: Nicola Canepa<canep...@mmfg.it>
Cc:"firstname.lastname@example.org" <email@example.com>, Cal Sawyer
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>:
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.
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
IPA server. This was never flagged up under Linux, btw. It has not
anything, however, other than not prompting for password changes that
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
didn't wait long enough. 10 mins is of course unacceptable :) "su -
and "login user" fail outright after rejecting accept any user's
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 per
linsec.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
Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 |
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
I disabled anonymous searches in 389-ds, by the way.
Il 21/12/15 07:50, John Obaterspok ha scritto:
Does a kinit work from a terminal? Does it work if you use "kinit user"
just if you use "kinit <user@REALM.suffix>user@REALM.suffix"
2015-12-20 15:09 GMT+01:00 Cal Sawyer <ca...@blue-bolt.com>:
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
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
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
truth, there so much stuff there and being rather inexperienced with
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
authenticating against our existing OpenLDAP server (which IPA is
replace) right up to 10.10.5 with no zero to our Directory Utility
Hoping someone here has some contemporary experience with OSX and IPA
for whom this issue rings a bell?
Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 <%2B44%20%280%2920%207637%205575> |
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project