CIFS authentication with LDAP

[rkaramchedu1]

I *think* this is a supposedly supported and possible configuration, however it does not work in my tests.

Where To: Get a mac client to mount a SAMBA share from a NetApp Filer, which is using LDAP for user authentication

Configuration Steps

1. Setup a LDAP server with at least 1 posixAccount user object. -- DONE

2. Setup the Simulator with LDAP using options.ldap settings and editing /etc/nsswitch.conf -- DONE

3. Perform cifs setup and configure to use LDAP (#4 in the cifs setup) -- DONE

4. Verify on the console that LDAP lookups can be performed (using the getXXbyYY getpwbyname_r <username>) command. -- DONE

5. Verify CIFS authentication from a CIFS client -- NOT DONE. NO WORK.

I am stuck at #5. Even with cifs trace logins on and ldap server logs revved up, when I attempt a CIFS authentication from my mac, nothing happens. No log entries in the LDAP server and no message on the filer console.

Any thoughts ?

[kusek]

Just to confirm - What method are you attempting to connect from your mac client?

As a way to test this, I could fire up my filer at home (or my simulator just as well) and connect it to my mbp.

Ideally, I'd like to replicate your scenario as closely as possible in order to watch it fail or succeed respectively.

Thanks!

Christopher

[rkaramchedu1]

Hi Christopher

I am using CIFS connection (Apple + K, cifs://<filername>/<share>)

cheers

- rajeev

[rkaramchedu1]

This appears to be a Apple-NTAP specific issue. Because I got this setup to work with a Windows system.

In Mac OS X case, the LDAP request is never made. The communication breakdown occurs (looks like) between mac os x and NTAP.

(I tested this with the new version of simulator 7.3 and still the same result)

It would be wonderful if some of the CIFS folks can chime in here..

[nbernstein]

what does the output of wcc and cifs security -s show?

Also check your security style on the volume/qtree you're trying to access. (qtree status)

-n

[rkaramchedu1]

Well..with LDAP authentication, wcc does not put out any output since it is not joined into any domain. There is no windows domain to join.

The qtree security style is mixed. (I even tried ntfs).

[cebulrdcis]

I will try this one in a simulator..

hope I'm successfulllll

[BrendonHiggins]

They may help

http://clctext.tlt.psu.edu/labs/mac/resources/authdoc/ldapauthorization.aspx

[alopeznetapp]

Hello.

I am having trouble implementing the mapping windows user when the storage system is integrated with a UNIX LDAP.

Could you send me your configuration file usermap.cfg?.

Thanks in advance.

[fromero]

I am having exactly the same problem stuck at #5, except that I do get a password rejected message on

the filer console:

auth: login from xxxxxxxx is rejected because the filer encountered an error while processing the password provided

by the user: user password rejected.

One other thing I have read is that the filer doesn't support md5 hashing. How can this get disabled in the ldap

configuration.

Does the command getXXbyYY returns the type of hasing being used in the ldap server?

I mean is if the line pw_passwd returned by the command.

[rkaramchedu1]

[Been a while since I played with ldap configuration]

I *think* an individual object can override the server specific setting by specifying the hash method in the password attribute, depending on the ldap policy. There's a server specific setting that dictates how all the password encryptions are done, which is probably where you are getting the MD5 hashing from. You may want to work with the LDAP admin and see if you can set the encryption of one test account to other hashing methods and see if that works. ({crypt}, {clear}, {3des}, {ssha} etc)

I know this does not answer your questions specifically (not mine, for that matter), but HTH.

[fromero]

I tried the crypt hashing method as it was suggested by the NetApp folks but it yielded the same result,

previously I have tried also the cleartext in slapd.conf to no avail. Is quite frustrating.... I can see the

machine talking to the ldap server and mapping the windows user to the unix user but it goes again and

rejects the password.

[fromero]

Gentlemen,

I found a soultion to my problem not sure if this applies specifically to the original problem that was posted in this

thread but it fixed my problem. However, something to have in your little bag of tricks.

Turns out that with openldap in a RedHat system there is a perl module to where the smbldap-passwd command points

to, to get the hashing mode. The name of the file is smbldap_conf.pm and is located in /var/lib/samba/sbin/

there are two lines there, one a comment that reads:

#Unix password encryption {CRYPT, MD5, SMD5, SSHA, SHA}

the other is the actual string that says how the hashing is done.

$hash_encryption="SSHA"

I changed this line to CRYPT, re-entered the user password with smbldap-passwd.pl and Voila!!

users successfully authenticated and mapped drives. Run the getXXbyYY command and got the right encryption type.

Now,  I am trying to point users straight into their home dirs instead of the root share that contains all users home dirs.

I am using usermap but not sure if that file helps to achieve this. Any suggestions? Thanks.

[nerscsysadm]

Hi, Iive read almost everything on internet and manuals and still stuck on #5.

I've a Mac OS X 10.5 server with OpenLDAP and the NetAPP Simulator 8.0 and this is the result so far:

netapp*> getXXbyYY getpwbyname_r [username]

pw_name = [username]

pw_passwd = {clear}********

pw_uid = 12345678, pw_gid = 20

pw_gecos =

pw_dir = /[path]/[to]/[username]

pw_shell = /bin/tcsh

In the log on the server I get:

Mar 18 16:41:00 [server] slapd[74]: SASL [conn=1204363] Failure: Couldn't find mech DIGEST-MD5

Mar 18 16:41:00 [server] slapd[74]: bind: invalid dn ([ldap_admin])

This is the options I have on the NetApp simulator:

netapp*> options ldap

ldap.ADdomain                          

ldap.base                    dc=[my],dc=[domain]

ldap.base.group              cn=groups,dc=[my],dc=[domain]

ldap.base.netgroup                     

ldap.base.passwd             cn=users,dc=[my],dc=[domain]

ldap.enable                  on        

ldap.minimum_bind_level      anonymous 

ldap.name                    [ldap_admin]  

ldap.nssmap.attribute.gecos  gecos     

ldap.nssmap.attribute.gidNumber gidNumber 

ldap.nssmap.attribute.groupname cn        

ldap.nssmap.attribute.homeDirectory homeDirectory

ldap.nssmap.attribute.loginShell loginShell

ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup

ldap.nssmap.attribute.memberUid memberUid 

ldap.nssmap.attribute.netgroupname cn        

ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple

ldap.nssmap.attribute.uid    uid       

ldap.nssmap.attribute.uidNumber uidNumber 

ldap.nssmap.attribute.userPassword userPassword

ldap.nssmap.objectClass.nisNetgroup nisNetgroup

ldap.nssmap.objectClass.posixAccount posixAccount

ldap.nssmap.objectClass.posixGroup posixGroup

ldap.passwd                  ******    

ldap.port                    636       

ldap.servers                 [ldap.my.domain]

ldap.servers.preferred       [ldap.my.domain]

ldap.ssl.enable              on        

ldap.timeout                 20        

ldap.usermap.attribute.unixaccount unixaccount

ldap.usermap.attribute.windowsaccount windowsaccount

ldap.usermap.base                      

ldap.usermap.enable          off

Any help appreciated!

Regards,

Lars-Gunnar Persson

[rkaramchedu1]

Mar 18 16:41:00 [server] slapd[74]: SASL [conn=1204363] Failure: Couldn't find mech DIGEST-MD5

Mar 18 16:41:00 [server] slapd[74]: bind: invalid dn ([ldap_admin])

Looks like your ldap server (slapd) is receiving SASL bind call (either it is set on the server to accept only SASL connections or it's the client requesting). Note that this has nothing to do with User Authentication and its encryption.. (think of this has handshake that happens much before).

It seems like client is requesting a SASL bind with DIGEST-MD5 mechanism that the server is not configured to support  - With that being the case, the subsequent ldap bind-dn is failing. If this handshake is not successful, then no subsequent ldap queries are allowed.

HTH

[nerscsysadm]

rkaramchedu1 wrote:
Mar 18 16:41:00 [server] slapd[74]: SASL [conn=1204363] Failure: Couldn't find mech DIGEST-MD5
Mar 18 16:41:00 [server] slapd[74]: bind: invalid dn ([ldap_admin])
Looks like your ldap server (slapd) is receiving SASL bind call (either it is set on the server to accept only SASL connections or it's the client requesting). Note that this has nothing to do with User Authentication and its encryption.. (think of this has handshake that happens much before). 
It seems like client is requesting a SASL bind with DIGEST-MD5 mechanism that the server is not configured to support  - With that being the case, the subsequent ldap bind-dn is failing. If this handshake is not successful, then no subsequent ldap queries are allowed.
HTH

Since the client is the OnTap 8.0 simulator, do you know how to change the requesting SASL bind to something else than DIGEST-MD5?

Regards,

Lars-Gunnar

[rkaramchedu1]

It's a bit late on this reply but was looking into the ldap stuff cause someone else asked me a question on it..

The options ldap.name and ldap.passwd are used for SASL binding. You have a value set for ldap.name. Blank that out and for good measure, blank the ldap.passwd as well (note that you'll still see the six ***s after this). That should set non-SASL bind with your settings.

[sam_wozniak]

I'd really like to know how to change the requesting SASL bind to something else besides DIGEST-MD5.  Is it possible?  We're running DOT 8.1.1 and not in a Sim. 

[rkaramchedu1]

After testing, found out that method is the only method that works with NetApp LDAP.. wish this was documented this a bit better...

[BRLUNDDAL]

But a non-SASL bind against an Open Directory server returns passwords in Clear text, and Samba on Macs don't accept Clear Text passwords.

Edit: Found out how to enable Clear Text password by editing/creating the nsmb.conf file (Btw. the same works in Lion even though it doesn't use Samba anymore).

Another thing I discovered in my environment, where the LDAP is an Apple Open Directory server, is that ldap.nssmap.attribute.userPassword should be set to Password instead of userPassword.