LDAP authentication with CIFS - password not in database

[Normand Leclerc]

Hi,

I wanted to share my user database between servers. I decided to give ldap a try. Before I get asked, I am on 9.3.

Right now, I am using an unencrypted jailed openldap server. I have samba schema loaded and set the database up with basic entries as found on multiple forums. FreeNas connects to the database; samba too; everything is good.

I add a user, see it added in openldap. When I try to get to a share (let's say the user's home which was previously CIFS shared), I get a login failure.

In the logs I can see

smbldap_open_connection: connection opened
ldap_connect_system: successful connection to the LDAP server
init_sam_from_ldap: Entry found for user: test
ERROR: Got 0 entries for gid 20000, expected one
ERROR: Got 0 entries for gid 20000, expected one
ERROR: Got 0 entries for gid 20000, expected one
Forcing Primary Group to 'Domain Users' for test
ntlm_password_check: NO NT password stored for user test.
ntlm_password_check: Lanman passwords NOT PERMITTED for user test
init_ldap_from_sam: Setting entry for user: test
check_winbind_security: Not using winbind, requested domain [EMBRIONIX] was for this SAM.
check_ntlm_password: Authentication for user [test] -> [test] FAILED with error NT_STATUS_WRONG_PASSWORD
SPNEGO login failed: NT_STATUS_WRONG_PASSWORD
NT error packet at ../source3/smbd/sesssetup.c(263) cmd=115 (SMBsesssetupX) NT_STATUS_LOGON_FAILURE
Server exit (failed to receive smb request)

ldapsearch won't find any ntpassword either. I can't figure out why my password won't make it to the database.

Anyone can help?

Thanks,

tcn

 

[dlavigne]

The requirements for CIFS sharing using LDAP were increased in 9.3. From the first note in http://doc.freenas.org/9.3/freenas_directoryservice.html#ldap:

LDAP authentication for CIFS shares will be disabled unless the LDAP directory has been configured for and populated with Samba attributes. The most popular script for performing this task is smbldap-tools and instructions for using it can be found at The Linux Samba-OpenLDAP Howto. In addition, the LDAP server must support SSL/TLS and the certificate for the LDAP server needs to be imported.

That last sentence is new since 9.2.x.

 

[Normand Leclerc]

Thanks for the pointer dlavigne.

The issue I have now is that I can access the database using ldapsearch on port 389 using TLS but the LDAP client from FreeNAS generates an unknown CA error at the server.

The certificate authority and certificate were generated using the FreeNAS GUI and exported to the jail. I figured I wouldn't have issues doing it this way...

I have seen bug: https://bugs.freenas.org/issues/8661 but I am not sure if my issue is of the same nature. There is no workaround to try.

 

[Normand Leclerc]

Hi,

Weird thing; I experimented and setting the UI to SSL while having TLS enabled on the server doesn't generate errors but FreeNAS is confused and fails to start the LDAP client.

Update: Nevermind this comment; it turns out that the access is unencrypted. Found this out when re-adding my security parameter at the server.

 

[Normand Leclerc]

Hi,

Got some progress on the issue. The certificate was wrong which prevented the whole TLS/SSL handshaking from working. Now to the real issue.

userPassword is not writable in the users I created using FreeNAS. I looked at the database and I think it is the posixAccount object class that is missing; actually I think a whole bunch of things are missing if I judge from my root entry in the LDAP database.

Anyone care to help?

Thanks,

tcn

 

[dlavigne]

userPassword is not writable in the users I created using FreeNAS. I looked at the database and I think it is the posixAccount object class that is missing; actually I think a whole bunch of things are missing if I judge from my root entry in the LDAP database

This sounds more like a bug report. If you create a report at bugs.freenas.org, post the issue number here.

 

[Normand Leclerc]

Thanks for your answer dlavigne;

Bug #9620 created; I hope it is a configuration issue though; it would be faster to fix....