Steven Bytnar
Level 1 (0 points)

Q: Authentication half broken. SSH, FTP, AFP fail logins; Messages, Wiki, Mail, Calendar allow logins

I installed the 10.9.1 update, Server 3.0.1 update and VPN update successfully and rebooted. Everything was working fine two days ago.

 

Yesterday, I decided I wanted to try to change the Open Directory Certificate.

I have a certificate that works fine with all other services.

So, using the Certificate tab, I changed my Open Directory Certificate to the other certificate.

After several attempts, the change did not stick and would revert to None or back to the automatically generated OD Root+Intermediate+Leaf certificates.

 

I stopped Open Directory.

Tried changing the Certificate again.

I started Open Directory.

Still the certificate change wouldn't stick.

Up to this point, I had no authentication problems.

 

So, I rebooted to see if the certificate change might take place at the next reboot. (It didn't.)

After the reboot, my Network Users cannot connect to the Time Machine (AFP) volume. The log files show: Error #-5023 on login. (afpUserNotAuth AFP User not authorized).

Manually establishing the afp:// connection in the Finder via Command-K results in the same authentication error code.

 

Network Users that could SSH in can't anymore. In this case, I get these interesting error messages in /var/log/system.log when a network user tries to login as "username" via SSH: (anonymized log file:)

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: AS-REQ username@SERVER.FQDN from 127.0.0.1:40813 for krbtgt/SERVER.FQDN@SERVER.FQDN

Dec 21 11:55:51 --- last message repeated 1 time ---

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: AS-REQ username@SERVER.FQDN from 127.0.0.1:36311 for krbtgt/SERVER.FQDN@SERVER.FQDN

Dec 21 11:55:51 --- last message repeated 1 time ---

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Client sent patypes: ENC-TS

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: ENC-TS pre-authentication succeeded -- user@SERVER.FQDN

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Requested flags: forwardable

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: TGS-REQ username@SERVER.FQDN from 127.0.0.1:64733 for host/servername.fqdn.com@SERVER.FQDN [canonicalize, forwardable]

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Server (host/servername.fqdn.com@SERVER.FQDN) has no support for etypes

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Failed building TGS-REP to 127.0.0.1:64733

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: TGS-REQ username@SERVER.FQDN from 127.0.0.1:47068 for host/servername.fqdn.com@SERVER.FQDN [forwardable]

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Server (host/servername.fqdn.com@SERVER.FQDN) has no support for etypes

Dec 21 11:55:51 servername.fqdn.com kdc[12177]: Failed building TGS-REP to 127.0.0.1:47068

Dec 21 11:55:51 servername.fqdn.com opendirectoryd[45]: GSSAPI Error:  Miscellaneous failure (see text (KDC has no support for encryption type (negative cache))

Dec 21 11:55:51 servername.fqdn.com sshd[17231]: error: PAM: authentication error for username from localhost via ::1

Dec 21 11:55:52 servername.fqdn.com sshd[17231]: Connection closed by ::1 [preauth]

 

My local user accounts can login via ssh.

 

PasswordServer Error Log does have an interesting error message too:

Dec 21 2013 11:28:57 270855us    Error: command: slapconfig -updateaddresses, exitcode = 70.

The PasswordServer Access Log shows no issues. In fact, this appears to be working.

If I run this command by hand, I get:

# slapconfig -updateaddresses

2013-12-21 17:54:58 +0000 slapconfig -updateaddresses

2013-12-21 17:54:58 +0000 _updateaddresses: Current addresses match those in the computer record; nothing to update

2013-12-21 17:54:58 +0000 _updateaddresses: successfully completed

 

On the server, "kinit -V username@SERVER.FQDN" succeeds for all network users.

 

 

Are there ways to more narrowly isolate login problems like this?

Does anyone have ideas on how to fix this half broken authentication problem?

Reinstallation or a full system restore from a Time Machine backup is not an option. I cannot afford to lose email/wiki activity.

 

If Apple doesn't really support changing the Open Directory certificate, why is it even an option in the Certificate configuration editor?

 

Frequently unhappy with OS X Server,

--Steve

Mac mini, OS X Mavericks (10.9.1), Mavericks Server

Posted on Dec 21, 2013 11:54 AM

by Steven Bytnar,Solvedanswer
Steven Bytnar Steven Bytnar
Level 1 (0 points)
A:

As a last ditch effort, I figured I would try the following TS article, even though it's not really the same problem:

http://support.apple.com/kb/TS5289?viewlocale=en_US&locale=en_US

 

Resolution

  1. Quit Server.app.
  2. On the Open Directory Server, execute these Terminal commands:
    sudo touch /var/db/openldap/migration/.rekerberize
    sudo killall PasswordService
  3. Open Server.app.

 

It works! This seems to have immediately fixed the authentication problem I've posted about.

Just to make sure, I rebooted and authentication is still working.

 

Yep, changing the OpenDirectory certificate is still an issue, but I'm not sure I want to battle that right now.

 

--Steve

Posted on Dec 21, 2013 7:28 PM

Close
Steven Bytnar

Q: Authentication half broken. SSH, FTP, AFP fail logins; Messages, Wiki, Mail, Calendar allow logins

  • All replies
  • Helpful answers

  • by Gavin Lawrie,

    Gavin Lawrie Gavin Lawrie Dec 21, 2013 4:32 PM in response to Steven Bytnar
    Level 2 (413 points)
    Mac App Store
    Dec 21, 2013 4:32 PM in response to Steven Bytnar

    Hi Steven

     

    There appears to be a problem with OS X Server 3 and some certificates that expresses itself as a refusal by OD to use the certificate.  But it is not clear what the cause of the problem is, nor how it might get resolved.

     

    The issue has appeared in several threads - for example this one concerning problems with certificates issued by Comodo.  In that case  it seems to be a classic case of Apple blaming the Certificate provider, and certificate provider blaming Apple - and as a result little happening to resolve.

     

    Sorry I can offer a fix, but some have suggested work-arounds in the the various threads about this issue in these fora - maybe one of them will work for you.

     

    We seem to have a similar setup to you - and have the problem (with a Comodo certificate) - but have not been helped by any of the suggested fixes.

     

    HTH

  • by Steven Bytnar,

    Steven Bytnar Steven Bytnar Dec 21, 2013 5:21 PM in response to Gavin Lawrie
    Level 1 (0 points)
    Dec 21, 2013 5:21 PM in response to Gavin Lawrie

    I'm not as worried about the Open Directory certificate issue.

     

    The show stopper is that my Network Users can't use Time Machine, SSH or FTP!

    It looks like both network and local users cannot login to FTP.

     

    --Steve

  • by Gavin Lawrie,

    Gavin Lawrie Gavin Lawrie Dec 21, 2013 6:00 PM in response to Steven Bytnar
    Level 2 (413 points)
    Mac App Store
    Dec 21, 2013 6:00 PM in response to Steven Bytnar

    Hmm. We have not had any problems with ssh, FTP, AFP etc. we don't use the TM service. But we do have the OD cert issue. Sounds like you've got some other thing going on as well as the cert thing.

  • by Steven Bytnar,Solvedanswer

    Steven Bytnar Steven Bytnar Dec 21, 2013 7:28 PM in response to Gavin Lawrie
    Level 1 (0 points)
    Dec 21, 2013 7:28 PM in response to Gavin Lawrie

    As a last ditch effort, I figured I would try the following TS article, even though it's not really the same problem:

    http://support.apple.com/kb/TS5289?viewlocale=en_US&locale=en_US

     

    Resolution

    1. Quit Server.app.
    2. On the Open Directory Server, execute these Terminal commands:
      sudo touch /var/db/openldap/migration/.rekerberize
      sudo killall PasswordService
    3. Open Server.app.

     

    It works! This seems to have immediately fixed the authentication problem I've posted about.

    Just to make sure, I rebooted and authentication is still working.

     

    Yep, changing the OpenDirectory certificate is still an issue, but I'm not sure I want to battle that right now.

     

    --Steve