OpenDirectory Yosemite SSL LDAP Cert Error

[David Snider]

Hello, I've been trying to get authentication working since upgrading to FreeNas 9.3. The error I'm getting is:

Code:

Dec 22 10:36:12 shiraz manage.py: [common.freenasldap:251] FreeNAS_LDAP_Directory.open: uri = ldap://blanc.thesniderpad.com:389
Dec 22 10:36:12 shiraz manage.py: [common.freenasldap:254] FreeNAS_LDAP_Directory.open: initialized
Dec 22 10:36:12 shiraz manage.py: [common.freenasldap:177] FreeNAS_LDAP_Directory[ERROR]: An LDAP Exception occured
Dec 22 10:36:12 shiraz manage.py: [common.freenasldap:181] FreeNAS_LDAP_Directory[ERROR]: info: 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate)'
Dec 22 10:36:12 shiraz manage.py: [common.freenasldap:184] FreeNAS_LDAP_Directory[ERROR]: desc: 'Connect error'

I've tried a ton of things, but am finding very little documentation on how to do this for 9.3.

I've created CA's from every cert in the /etc/certificates directory on my OS X server, tried each of them individually, and none work. Any suggestions?

 

[dlavigne]

That looks related to https://bugs.freenas.org/issues/6960 which should have been fixed for 9.3 RELEASE. Please create a bug report at bugs.freenas.org that includes your error messages, indicates this was an upgrade instead of a fresh install, as well as a reference to #6960 and post the issue number here.

 

[Mike Curd]

I am also seeing this in FreeNAS-9.3 using a fresh install and importing my config from FreeNAS-9.2.1.8. Services are secured on the Yosemite server using a third party SSL certificate.

Until there's a bit more guidance as to what certs are needed and where they should go (if this is expected behaviour and not a bug), I have worked around the issue by adding:

Code:

ldap_tls_reqcert = never

to the Auxiliary Parameters on the LDAP config page.

Obviously not ideal but in my case an acceptable short-term solution.

 

[None696]

I am having a similar issue. I tried adding

Code:

ldap_tls_reqcert = never

to the Auxiliary Parameters on the LDAP config page.

Now I am able to log in (both to AFP and via SSH), how ever it doesn't appear that group membership is being updated correctly.

getent group shows me LDAP groups

Code:

wheel:*:0
daemon:*:1
kmem:*:2
sys:*:3
tty:*:4
operator:*:5:uucp
mail:*:6
bin:*:7
news:*:8
man:*:9
games:*:13
ftp:*:14
staff:*:20
sshd:*:22
smmsp:*:25
mailnull:*:26
guest:*:31
bind:*:53
proxy:*:62
authpf:*:63
_pflogd:*:64
_dhcp:*:65
uucp:*:66
dialer:*:68
network:*:69
audit:*:77
www:*:80
nogroup:*:65533
nobody:*:65534
avahi:*:200
messagebus:*:201
hast:*:845
ladvd:*:78
webdav:*:666
com.apple.locales.DefaultLocale:*:1569626
com.apple.access_sessionkey:*:397
com.apple.access_disabled:*:396
com.apple.limited_admin:*:106
freenastimemachine:*:1029
freenassoftware:*:1028
mobilehomeusers:*:1031
freenasbackup:*:1030
pfsenseadmins:*:1026
freenasmedia:*:1027
workgroup:*:1025
admin:*:80
staff:*:20

However when I ssh into the server, my group membership isn't updated

Code:

[Derek@freenas /mnt/Data]$ whoami
Derek
[Derek@freenas /mnt/Data]$ groups
staff

To confirm that my LDAP server is working, here is the output from my laptop (also authenticated against the same server)

Code:

MBP-Retina:~ Derek$ whoami
Derek
MBP-Retina:~ Derek$ groups
staff mobilehomeusers freenastimemachine workgroup admin freenasmedia everyone netaccounts _appserverusr _appserveradm pfsenseadmins freenassoftware freenasbackup _appstore _lpadmin _lpoperator _developer com.apple.access_screensharing com.apple.access_ssh

 

[vrillusions]

Had the same issue, reason is by default ldap_schema is set to rfc2307bis which per docs:

With rfc2307, group members are listed by name in the memberUid attribute. With rfc2307bis and IPA, group members are listed by DN and stored in the member attribute.

If not specified it defaults to rfc2307 but the config had it defined as rfc2307bis. Adding the following fixed it for me (we use the memberUid attribute listed in each group)

Code:

ldap_schema = rfc2307

Remember to hit rebuild directory services cache afterwards. At that point you can run getent group and you should be able to see all the users listed for each group