-
All replies
-
Helpful answers
-
by Strontium90,Mar 14, 2016 7:33 AM in response to jean-Luc Evrard
Strontium90
Mar 14, 2016 7:33 AM
in response to jean-Luc Evrard
Level 5 (4,077 points)
Servers EnterpriseAs a test, create an account in the local domain ("local user" like the initial admin) or use the local admin account. Try authenticating to the server using that account. If it works, then you need to add the legacy authentication authorities to your OD account(s) and reset password.
DSLocal accounts still have ;ShadowHash;HASHLIST: AuthenticationAuthority while OD accounts only have PasswordServer and Kerberos.
Try connecting with a local account first. If it works, then you know it is the missing auth authorities. If so, simply add them to the required OD accounts.
Reid
Apple Consultants Network
Author - "El Capitan Server – Foundation Services"
Author - "El Capitan Server – Control & Collaboration"
Author - "El Capitan Server – Advanced Services"
-
by John Lockwood,Mar 14, 2016 8:33 AM in response to jean-Luc Evrard
John Lockwood
Mar 14, 2016 8:33 AM
in response to jean-Luc Evrard
Level 6 (9,349 points)
Servers EnterpriseI have not upgraded my OD server to El Capitan as yes but I checked my Yosemite OD server. It looks like Yosemite running Server.app 5.0.15 also as default does not support DIGEST-MD5.
If you launch Terminal.app and do the following on your OD Master you can see what authentication mechanisms are blocked.
sudo defaults read /Library/Preferences/OpenDirectory/Configurations/LDAPv3/127.0.0.1.plist
The relevant section seems to look like this -
ldap = {
"Denied SASL Methods" = (
"DIGEST-MD5"
);
While it would be easy enough to remove that entry one would suspect that if Apple felt it necessary to include it, it was for a good reason. My suspicion is that Apple regard DIGEST-MD5 as no longer being secure enough an authentication method and have therefore disabled it as above. However whether this is simply disabled just by this entry being in the plist or whether Apple have gone further and removed the code for it in Open Directory I don't know. If the former then removing this entry from the plist would in theory re-enable it at the risk of lowering security.
Note: The above plist is stored as a binary file, it not a plain-text xml file. Once can if needed convert between xml and binary formats using the plutil command.
-
Mar 14, 2016 9:36 AM in response to John Lockwoodby jean-Luc Evrard,I tried this way but it failed…
Still get the following message: odusers_krb_auth: Error obtaining credentials for…
The _krb_ in the message suggests that MD5 is not present…
-
by John Lockwood,Mar 14, 2016 10:20 AM in response to jean-Luc Evrard
John Lockwood
Mar 14, 2016 10:20 AM
in response to jean-Luc Evrard
Level 6 (9,349 points)
Servers Enterprisekrb could imply kerberos authentication which is a totally different mechanism and nothing to do with DIGEST-MD5 or CRAM-MD5.
Originally Apple used MIT for their implementation of Kerberos, they now use Heimdal. Personally I think Heimdal is a lot worse and more troublesome especially when trying to link non-Mac systems to it. Whether this is Heimdal's fault or Apple's I don't know.
As it seems your Unix system is currently trying to use Kerberos it needs configuring to join the Mac Kerberos 'realm' and to have a kerberos keytab configuration file. I did last year try linking a Linux machine via Kerberos to a Mac server and tried on the Linux machine both the MIT implementation and the Heimdal implementation and could not get either to link to the Mac. I gave up and switched to bog-standard LDAP authentication which did work.
PS. I don't think this is your issue but even once you have done the basic Kerberos setup one of the most common issues with Kerberos is that you must have completely correct forward and reverse DNS lookups working on all servers. This applied to MIT kerberos as well. As I said I don't think this is your issue because I feel you have not yet done any Kerberos setup on the Unix machine or that the Mac and Unix machines are currently on completely separate Kerberos realms.