<html>
  <head>
    <meta content="text/html; charset=iso-8859-15"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    I tried enabling the anonymous bind and now also the directory
    browser (and all the login process) works as expected.<br>
    <br>
    Nicola<br>
    <br>
    <div class="moz-cite-prefix">Il 21/12/15 17:39, Cal Sawyer ha
      scritto:<br>
    </div>
    <blockquote cite="mid:56782B3E.2030103@blue-bolt.com" type="cite">
      <meta content="text/html; charset=iso-8859-15"
        http-equiv="Content-Type">
      Thanks, John and Nicola<br>
      <br>
      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<br>
      <br>
      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.<br>
      <br>
      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<br>
      <br>
      DNS is fine and i can resolve ldap and kerberos SRV records from
      the Mac<br>
      <br>
      In line with Nicola's experience, i can browse groups and users in
      the Directory Editor and all attributes appear spot on.<br>
      <br>
      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.<br>
      <br>
      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<br>
      <br>
      thanks, everyone<br>
      <pre class="moz-signature" cols="72">Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.blue-bolt.com">www.blue-bolt.com</a>

</pre>
      <div class="moz-cite-prefix">On 21/12/15 07:57, Nicola Canepa
        wrote:<br>
      </div>
      <blockquote cite="mid:5677B0F0.6000105@mmfg.it" type="cite">
        <meta content="text/html; charset=iso-8859-15"
          http-equiv="Content-Type">
        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)<br>
        I disabled anonymous searches in 389-ds, by the way.<br>
        <br>
        Nicola<br>
        <br>
        <div class="moz-cite-prefix">Il 21/12/15 07:50, John Obaterspok
          ha scritto:<br>
        </div>
        <blockquote
cite="mid:CAOscVdLQghGJRUbHX3mpO11H4wnACoXsv9U1NcyU-D2m=-mMHA@mail.gmail.com"
          type="cite">
          <div dir="ltr">Hi Cal,
            <div><br>
            </div>
            <div>Does a kinit work from a terminal? Does it work if you
              use "kinit user" or just if you use "kinit <a
                moz-do-not-send="true" class="moz-txt-link-abbreviated"
                href="mailto:user@REALM.suffix"><a class="moz-txt-link-abbreviated" href="mailto:user@REALM.suffix">user@REALM.suffix</a></a>"</div>
            <div><br>
            </div>
            <div>-- john</div>
            <div><br>
            </div>
          </div>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">2015-12-20 15:09 GMT+01:00 Cal
              Sawyer <span dir="ltr"><<a moz-do-not-send="true"
                  href="mailto:cal-s@blue-bolt.com" target="_blank">cal-s@blue-bolt.com</a>></span>:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
                all<br>
                <br>
                I'm attempting to set up LDAP auth (against IPA server
                4.10) from a OSX 10.10.5 (Yosemite) client<br>
                <br>
                Using the excellent instructions at <a
                  moz-do-not-send="true" class="moz-txt-link-freetext"
href="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"><a class="moz-txt-link-freetext" href="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</a></a>,
                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.<br>
                <br>
                In spite of this, i'm unable to authenticate as any
                IPA-LDAP user on this system<br>
                <br>
                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<br>
                <br>
                The <a moz-do-not-send="true" href="http://linsec.ca"
                  rel="noreferrer" target="_blank">linsec.ca</a>
                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.<br>
                <br>
                Hoping someone here has some contemporary experience
                with OSX and IPA and for whom this issue rings a bell?<br>
                <br>
                many thanks<span class="HOEnZb"><font color="#888888"><br>
                    <br>
                    Cal Sawyer | Systems Engineer | BlueBolt Ltd<br>
                    15-16 Margaret Street | London W1W 8RW<br>
                    <a moz-do-not-send="true"
                      href="tel:%2B44%20%280%2920%207637%205575"
                      value="+442076375575" target="_blank">+44 (0)20
                      7637 5575</a> | <a moz-do-not-send="true"
                      href="http://www.blue-bolt.com" rel="noreferrer"
                      target="_blank">www.blue-bolt.com</a><br>
                            <br>
                    <br>
                    -- <br>
                    Manage your subscription for the Freeipa-users
                    mailing list:<br>
                    <a moz-do-not-send="true"
                      href="https://www.redhat.com/mailman/listinfo/freeipa-users"
                      rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
                    Go to <a moz-do-not-send="true"
                      href="http://freeipa.org" rel="noreferrer"
                      target="_blank">http://freeipa.org</a> for more
                    info on the project<br>
                  </font></span></blockquote>
            </div>
            <br>
          </div>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="72">-- 

Nicola Canepa
Tel: +39-0522-399-3474
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:canepa.n@mmfg.it">canepa.n@mmfg.it</a>
---
Il contenuto della presente comunicazione č riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avrā valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, nč rinuncia o riconoscimento di diritti, debiti e/o crediti, nč sarā impegnativa, qualora non sia sottoscritto successivo accordo da chi puō validamente obbligarci. Non deriverā alcuna responsabilitā precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti.

The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts  and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties.
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 

Nicola Canepa
Tel: +39-0522-399-3474
<a class="moz-txt-link-abbreviated" href="mailto:canepa.n@mmfg.it">canepa.n@mmfg.it</a>
---
Il contenuto della presente comunicazione č riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avrā valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, nč rinuncia o riconoscimento di diritti, debiti e/o crediti, nč sarā impegnativa, qualora non sia sottoscritto successivo accordo da chi puō validamente obbligarci. Non deriverā alcuna responsabilitā precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti.

The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts  and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties.
</pre>
  </body>
</html>