Using NFS instead of Samba for Mac homes

UCS - Univention Corporate Server
, , ,
#1

UCS 4.2-2
Mac OS X 10.12.6

I’ve been trying a few things and I’m not sure how this works with UCS. Samba network homes are not working very well for us. And I’m trying to move back to NFS homes. I can see the ldap attribute setup for it and while I can bind via Active Directory and specify the NFS protocol in Apple Directory setup it won’t find the home folder upon login like it does when using SMB. Yes, the NFS home directory matches the /etc/exports of the file server it’s connecting to.

I’ve also been trying to connect Apple’s Directory Utility directly to the OpenLDAP side of UCS but it refuses to connect at all when I attempt to bind or browse the directory from within the utility. I know I’m using the correct DN for authentication (uid=administrator,cn=users,dc=mydomain,dc=org). I can connect to OpenLDAP with a 3rd party LDAP utility with the same DN and password but not at all from the Directory Utility app. I have specified RFC2307 as the LDAP Mappings as well as port 7389. Since UCS uses self signed SSL for 7636 that connection fails even though we have added our own SSL for this UCS DC master.

#2

Maybe you can activate more debug in the Apple’s Directory Utility? I don’t have much experience with Mac OS X systems, so I don’t know if it is possible.

You can activate debug on UCS side for OpenLDAP, maybe it helps:

ucr set ldap/debug/level=256
/etc/init.d/slapd restart

Afterwards, you might find more info in /var/log/syslog.

#3

What I see on the server is this:

Dec 29 07:47:52 ad slapd[17477]: conn=1027 fd=22 ACCEPT from IP=x.x.x.x:49281 (IP=0.0.0.0:7389)
Dec 29 07:47:52 ad slapd[17477]: conn=1027 fd=22 closed (connection lost)

If I try the same LDAP settings in a 3rd party LDAP browser utility it connects fine.

#4

Maybe you can create a network trace via tcpdump or wireshark?

#5

I will try that shortly. Is rfc2307 on by default for the UCS OpenLDAP install? Do I need to do a custom mapping of LDAP attributes? From what I saw between mining the attributes from the 3rd party utility is that they line up with rfc2307 as far as mapping goes in Apple’s Directory Utility app. I’m now on UCS 4.3.

#6

Can I email you the PCAP file? I don’t feel comfortable with it being posted publicly.

#7

From what I can read in cleartext communications between the client – > server:

objectClass 0_..supportedSASLMechanisms..defaultNamingContext..namingContexts..schemaNamingContext..saslReal

It’s also looks like it wants to send a password in CRAM-MD5 and when it does send the hash of the AD’s administrator user it’s not the full DN it’s just “administrator” and the server replies back:

SASL(-13): user not found: no secret in database

Then the server responds with:

namingContexts1..dc=mydomain,dc=org0K..supportedSASLMechanisms10..GSS-SPNEGO..GSSAPI..DIGEST-MD5..NTLM..CRAM-MD5

So the client again says CRAM-MD5 and the server says

SASL(0): successful result: security flags do not match required.0<1187924173.5045982@ad.mydomain.org>

The client sends “administrator” and hash of password again and again the server responds with the SASL(-13) error and it repeats the whole process again.

So it sounds like the mac and OpenLDAP aren’t communicating properly and the mac is trying to do a simple password (despite my entering of the full DN of the administrator user) in the “security” section of the Directory Utility.

The DN I’m using is uid=administrator,cn=users,dc=mydomain,dc=org

#8

Also of note the Apple Directory Utility cannot seem to bind to the UCS OpenLDAP implementation. I get a “Binding not supported” error on the Mac client.

#9

Are you going to respond or what? Is this a bug? I find your lack of communication disturbing.

#10

Sorry, I’m currently extremely busy. I hope that I have some hours next week. You can upload your PCAP file to https://upload.univention.de. Please insert the upload ID here or send it to feedback@univention.de.

#11

Gohmann the upload ID is upload_zGNmrb.bin

#12

Thanks. You are right it looks like a problem in the SASL negotiation. I don’t have a MAC here to test it but I found the following article:
http://pig.made-it.com/ldap-mac.html
There is a section about “Denying SASL Mechanisms”. Does it help?

#13

No it didn’t help. I pulled the .plist that this article references and it already has the Denied SASL Mechanism of “Digest-MD5” already added.

#14

Can you also deny CRAM-MD5?

#15

Made no difference denying CRAM-MD5 either.

#16

Can you try the following:

echo "mech_list: EXTERNAL PLAIN LOGIN GSSAPI GSS-SPNEGO"  >>/etc/ldap/sasl2/slapd.conf
/etc/init.d/slapd restart

Does it help?

#17

When searching to see the supported SASL mechanisms after running your command I see:

 ldapsearch -h 172.16.0.9 -p 7389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO

ldapsearch -h 172.16.0.9 -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: NTLM
#18

WAIT! I think it did work. I can now login, I forgot to specify search path because it’s not automatically added. It’s still creating a local home folder and not mounting an NFS home.

#19

This is the issue with NFS homes. The home shares don’t show up in the drop down menu. For some reason only one of my more recent shares shows up. Instead of the share where all the homes reside.

17 AM

#20

Here are the configurations for the two shares side by side. I’m not sure why the one on the right shows up in the “Home Share” drop down and the one on the left doesn’t.

48 PM

Mastodon