openldap-technical September 2016

openldap-technical@openldap.org

50 participants
44 discussions

Authenticating Mac OSX (El Capitan) sign-ons to an OpenLDAP directory?
by Kevin Long 04 Sep '16

04 Sep '16

Greetings, I have a directory I set up for a client that uses OpenLDAP for single sign-on for several web applications and email, but I’m hoping to get it to work for their computer lab as well (All OS X El capitan machines). It’s unclear to me whether I truly need to add the apple/samba schemas to OpenLDAP to appease OS X, or whether I can map more standard attributes from the cosine etc schema to whatever OS X is looking for. I’ve read many blogs posts and have yet to find documentation that I think covers all the bases, including these: http://pig.made-it.com/ldap-mac.html http://vuksan.com/linux/mac-os-x-ldap/openldap-mac-os-x-authentication.html https://hermanbanken.nl/2011/01/22/openldap-server-mac-osx-clients/ http://www.hawaii.edu/askus/1625 It seems like OS X changes may have rendered some of the existing blogs/documents out there outdated. We are willing to hire someone to help with getting this set up. Regards, Kevin Long

2 1

What am I doing wrong with these olcAccess settings?
by A M 04 Sep '16

04 Sep '16

Hello, I just need to allow a simple "bind" user to be able the perform the authenticated searches in the tree, while allowing all other users to consult their data without being able to modify them. So I have set the following primitive access rules: ------------------------------ olcAccess: {0}to attrs=userPassword by self write by dn.base="cn=Manager,dc=example,dc=com" write by anonymous auth by * none" olcAccess: {1}to * by self read by dn.base="cn=Manager,dc=example,dc=com" write by dn="uid=binduser,ou=Users,dc=example,dc=com" read ------------------------------- With these settings, I can in fact perform authenticated searches as dn="uid=binduser,ou=Users,dc=example,dc=com" with filter uid=username. But the weird thing is that all other non-privileged users cannot see their own data, although I have added "to * by self read".. What am I missing? Thanks ahead for any comment! Andy.

2 1

Change Defaulth ssha passoword encryption algorithm
by Net Warrior 04 Sep '16

04 Sep '16

Hi Guys I need some guidance on this, I configured a ppolicy for a DIT which has all the users in plain password, I added to following to the policy changetype: modify replace: olcPPolicyHashCleartext olcPPolicyHashCleartext: FALSE When the user reset it password, it changes from clear password to encrypted using ssha but I want to store them using md5crypt, what do I need to change in my configuration? Thank you very much for your time and support Regards

5 10

contextCSN attribute update on replication
by Óscar Remírez de Ganuza Satrústegui 04 Sep '16

04 Sep '16

Good morning, I am writting from IT Services from Universidad de Navarra. We have recently upgraded our openldap servers from openldap 2.4.34 with BDB 5.3.21 to openldap 2.4.44 with MDB databases. We have got configured replication from the master server [1] to some slave servers [2] (syncrepl refreshAndPersist), and it is working ok. Usually, when a change is made on master server, I can see how it is propagated and applied on the slave server. Using Auditlog Overlay I can see on the slave server: # modify 1470723918 dc=base,dc=com cn=Admin,dc=base,dc=com conn=-1 dn: ... changetype: modify replace: [..] # end modify 1470723918 And just after that, the contextCSN gets updated too: # modify 1470723918 dc=base,dc=com cn=Admin,dc=base,dc=com conn=-1 dn: dc=base,dc=com changetype: modify replace: contextCSN contextCSN: 20160809062518.877725Z#000000#000#000000 - # end modify 1470723918 Is this the normal behaviour? I do not see the contextCSN update on the accesslog database on the master server, nor on his Auditlog. So I do not know if contextCSN has been replicated from the master server, or the slave database is updating it. But I am seeing some weird things from time to time: sometimes, somehow, the contextCSN attribute does not get updated after the modification. Checking its value in the master server, I can see that it has been updated correctly, but not on the slave server. The strange thing is that it happens just like once every tens of changes. Could it be some kind of bad configuration?? On the previous openldap version, we were checking contextCSN value on master and slave servers in order to check the replication status. But right now, although replication is working ok, sometimes the contextCSN does not get updated on the slave sever, so we can not use it in order to check the replication status. Thank you so much for your help. Regards, [1] Master: * Accesslog Database: database mdb maxsize 1073741824 suffix cn=log directory /../openldap/var/accesslog rootdn "cn=Admin,dc=base,dc=com" index objectClass eq index entryCSN eq index reqEnd eq index reqResult eq index reqStart eq index reqDN eq index default eq overlay syncprov syncprov-reloadhint true syncprov-nopresent true * Main Database overlays: overlay syncprov syncprov-checkpoint 1000 60 overlay accesslog logdb cn=log logops writes logsuccess true logpurge 14+00:00 01+00:00 [2] Slave: syncrepl rid=1 provider="ldap://ldap-master.base.com:389/" type=refreshAndPersist retry="60 10 300 +" searchbase="dc=base,dc=com" logbase="cn=log" syncdata=accesslog logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" scope=sub schemachecking=off binddn=... *Oscar Remírez de Ganuza Satrústegui* IT Services Universidad de Navarra Tel. +34 948425600 x803130 http://www.unav.edu/web/it/

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2016