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'


Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 |

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

    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.


On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer < <>> 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 <>'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<> 
        To: Nicola Canepa<> <>
        Cc:"" <>  
<> <>,      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
            <> <>:
            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 
            I tried enabling the anonymous bind and now also the directory 
            (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 
            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 - 
            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 
            Directory Editor and all attributes appear spot on.

            Besides modding /etc/pam.d/authorization, adding a corrected
   to /LibraryPreferences and setting up the 
directory per
   <>, 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 
            or krb5 logs on the IPA master?  I've disabled the secondary to 
            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 
<tel:%2B44%20%280%2920%207637%205575>  | 

            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 
            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:

            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>

            -- john

            2015-12-20 15:09 GMT+01:00 Cal Sawyer<> 

            Hi, all

            I'm attempting to set up LDAP auth (against IPA server 4.10) from a 
            10.10.5 (Yosemite) client

            Using the excellent instructions at
            I've populated the specified files, d/l'd the cert, am able to 
            Users and Groups objects/attribs and browse both from within OSX's
            Directory Utility.    ldapsearch similarly returns the expected 

            In spite of this, i'm unable to authenticate as any IPA-LDAP user 
on this

            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

   <>  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 
slated to
            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 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> | 

    Manage your subscription for the Freeipa-users mailing list:
    Go to for more info on the project

Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to