openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

separate login/password for several services?
by Zeus Panchenko 09 Aug '13

09 Aug '13

hi all, please, may somebody advice I need to set separate credentials for each service I provide (optionally) to my users I think of something like this: dn: uid=target-user,ou=People,dc=ibs userPassword: ****** ... authorizedService: xmpp authorizedService: smtp authorizedService: pop authorizedService: imap authorizedService: mail ... loginSMTP: mail-send-login passwSMTP: xxx loginPOP3: mail-get-login passwPOP3: yyy ... loginXMPP: login-xmpp passwXMPP: zzz can I achieve it? from which side to approach the issue? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

5 10

Re: Schema Replication and data replication
by Christian Kratzer 08 Aug '13

08 Aug '13

Hi, On Thu, 8 Aug 2013, espeake(a)oreillyauto.com wrote: > Christian, > > The olcServerID goes in the cn=config file correct? I will do a ldapmodify to change this. yes. use the following: dn: olcDatabase={0}config changetype: modify replace: olcServerID olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com olcServerID: 2 ldap://tntest-ldap-master-2.oreillyauto.com > The consumer config is what was on there and that's why I asked the question about wiping it out and then using slapcat to put it back in. slapcat NEVER shows the checksums and protecting comments that you only see when you go looking at the files under slapd.d # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 3411e7fc Once you have the correct configuration on one server dump it with slapcat -n0 and import it to the second server using slapadd -n0. Be sure to wipe ALL of the contents in the slapd.d directory before importing with slapadd. ps: please keep the mailinglist on the Cc: so what we learn from this is for the greater good. Greetings Christian > > Thanks, > Eric > > > > -----openldap-technical-bounces(a)OpenLDAP.org wrote: -----To: espeake(a)oreillyauto.com > From: Christian Kratzer > Sent by: openldap-technical-bounces(a)OpenLDAP.org > Date: 08/08/2013 06:58AM > Cc: openldap-technical(a)openldap.org > Subject: Re: Schema Replication and data replication > > Hi, > > On Wed, 7 Aug 2013, espeake(a)oreillyauto.com wrote: > > > > > So we are cooking with warm oil and I wan to the cooking with hot oil!!!! > > > > I have been able to get upgraded 2.4.28 on open ldap. Having issue with > > getting a good build of 2.4.35. But that isn't the problem. Below is the > > log on my log from one of my consumers after starting the slapd service. > > > <snipp> > > > > Here is where is stops. > > > > Here in the ldif file from my master: > > > > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > > # CRC32 3411e7fc > > use slapcat -n0 instead of copying manually the files from the slapd.d directory. > > > dn: olcDatabase={0}config > > objectClass: olcDatabaseConfig > > olcDatabase: {0}config > > olcUpdateRef: ldap://tntest-ldap-master-1.oreillyauto.com > > olcsyncrepl: rid=002 provider=ldap://tntest-ldap-master-1.oreillyauto.com > > type=refreshAndPersist retry="10 +" searchbase="cn=config" > > bindmethod=simple binddn="uid=admin,dc=oreillyauto,dc=com" > > credentials=<password> > > olcAccess: to * by dn="uid=admin,dc=oreillyauto,dc=com" write by > > dn="uid=ldapadmin,ou=system,dc=oreillyauto,dc=com" write by * none > > olcRootDN: cn=admin,cn=config > > olcRootPW:: c2VjcmV0 > > structuralObjectClass: olcDatabaseConfig > > entryUUID: 35b75e72-93c2-1032-9ca4-711c013d2dcb > > creatorsName: cn=config > > createTimestamp: 20130807153144Z > > entryCSN: 20130807153144.468097Z#000000#000#000000 > > modifiersName: cn=config > > modifyTimestamp: 20130807153144Z > > > > Here is the ldif from my consumer: > > > > dn: olcDatabase={0}config > > objectClass: olcDatabaseConfig > > olcDatabase: {0}config > > olcRootDN: cn=admin,cn=config > > olcRootPW: secret > > structuralObjectClass: olcDatabaseConfig > > olcsyncrepl: {0}rid=002 > > provider=ldap://tntest-ldap-master-1.oreillyauto.com type=refreshOnly > > retry="5 +" searchbase="cn=config" bindmethod=simple > > binddn="cn=admin,cn=config" credentials=<password> schemachecking=on > > olcAccess: to * by dn="uid=admin,dc=oreillyauto,dc=com" write by > > dn="uid=ldapadmin,ou=system,dc=oreillyauto,dc=com" write by * none > > entryUUID: f074ba7c-09ed-1030-952b-0bb60fbd91a8 > > creatorsName: cn=config > > createTimestamp: 20110503162710Z > > entryCSN: 20110503162710.319234Z#000000#000#000000 > > modifiersName: cn=config > > ModifyTimestamp: 20110503162710Z > > > > both your entryCSN have #000# for the serverID. Even though it seems you > have somehow modified the configuration. > > Your replication cannot work when you have not configured a serverID. > > You need at least the following in your configs. > > olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com > olcServerID: 2 ldap://tntest-ldap-master-2.oreillyauto.com > > Also why does the ModifyTimestamp: attribute from your second server start with a capital 'M'. > > Are you still somehow manually poking at the files in slapd.d ? > > Please use slapcat / slapadd with the -n0 option to export and import your configuration. > > > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: ck(a)cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer > > > -- > This message has been scanned for viruses and dangerous content, > and is believed to be clean. > Message id: 7014E600847.AEC40 > > > This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended > recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

4 5

DB_Config and log files
by jeevan kc 08 Aug '13

08 Aug '13

Hello thereMy DB_CONFIG looks like this set_cachesize 0 716800 0set_lg_bsize 2097512set_lg_dir /usr/local/var/openldap-logsset_flags DB_LOG_AUTOREMOVE Recently , we have few batch processes running in the LDAP server for Datawarehouse groups and other apps and this is causing DB logs to grow . When I do a ls -l the size of the logs are almost 4GB in size. This is causing trouble and we don't want this many logs. How do I limit the log size so that it doesn't exceed lets say 1 GB . These DB logs are of very little importance to us. We periodically do a backup using slapcat and we can use this in case we have a fatal crash .Please throw some light on how to limit these DB logs . Thanks

1 0

group name of a user
by zeya badar 08 Aug '13

08 Aug '13

Hi I am very new to openldap so i need some help on that suppose i created one group and added users as a member but when i am searching a user i am unable to find user's group name? in which attribute we can find user's group name can anyone help me to get group name of a user? Thanks & Regards Zeya Alam Badar

2 1

[OT] is there any theory behind (|) being false?
by Zhang Weiwu 08 Aug '13

08 Aug '13

Quote from RFC 4526: > An 'and' filter with zero elements always evaluates to True. An 'or' > filter with zero elements always evaluates to False. My question is, is there any theory this decision is based on, or is it randomly chosen? Why not (&) being false, and (|) being true? Or more specifically, we know 'FALSE && NULL' is FALSE, we know 'TRUE || NULL' is TRUE, but is there reason 'NULL && NULL' being true and 'NULL || NULL' being false? Thanks:)

2 1

Replicating Schema, olcAccess and olcLimits
by Andrew Devenish-Meares 07 Aug '13

07 Aug '13

Hi List, I'm attempting to set up replication of schema, olcAccess and olcLimits. It appears replicating the schema works, but the olcAccess and olcLimits do not appear to replicate under olcDatabase={2}bdb,cn=config. (Additionally the DIT under dc=une,dc=edu,dc=au is also replicated without issue). The syncprov overlay is in place root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcOverlay={0}syncprov,olcDatabase={0}config,cn=config SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov The SyncUser has access to read the cn=schema,cn=config and olcDatabase={2}bdb,cn=config branches: root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcDatabase={0}config,cn=config olcAccess SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcDatabase={0}config,cn=config olcAccess: {0}to dn.subtree="cn=schema,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {1}to dn.subtree="olcDatabase={2}bdb,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {2}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config On the consumer side, I've added the following two olcSyncRepl enteries to the olcDatabase={2}bdb,cn=config: root@ldap-slave-dev-00 [DEV] ~/ldap-slave-config/# ldapsearch -Y EXTERNAL -H ldapi:/// -LL -b olcDatabase={0}config,cn=config olcSyncRepl SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="cn=schema,cn=config" type=refreshAndPersistinterval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=003 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="olcDatabase={2}bdb,cn=config" attrs="olcDbIndex,olcDbConfig,olcAccess,olcLimits" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 I don't follow why this doesn't work. Any suggestions? Thanks -- Andrew Devenish-Meares Solutions Analyst Information Technology University of New England Armidale NSW 2351 e: adevenis(a)une.edu.au p: 02 6773 4098 w: http://une.edu.au/itd

2 3

Replicate translucent ldap
by Zoli Szemelyesen 07 Aug '13

07 Aug '13

Greetings, I have an unusual setup and would like to hear opinions about it. We have an AD in a central office. I have to replicate an ou portion of it once a day to a remote location. (Using the remote AD is technically not an option here and a daily update is sufficient.) I add new attributes locally in a translucent setup. These attributes are used only locally and meddling with the AD is not an option either. Access to this is ok, but I need to have copies of the overlayed ldap. (Reasons: Local redundancy is important to keep SLA with automated systems using ldap and also have another local office nearby with slow/bad connection so a local copy is needed there as well). Reading docs and googling around I couldn't find a good and working solution for the local copies. - Doing dumps and copy them over could work but it's a crappy solution imho. - Replicating the 'AD portion' and the local db separately and doing 'local overlay' on the backup nodes might work but I'd prefer to use an already set up db instead of dynamically rebuild it in multiple locations). - Doing 'classic' replication is not possible afaik. Ideas or experience with similar scenario? Thanks in advance McLoud

1 0

Editing Schema
by Bram Cymet 06 Aug '13

06 Aug '13

Hi, I am wondering the best way to edit a schema after it is loaded. I would like to change the syntax OID for an object type. I have tried using Apache Directory Studio to do this and it just causes OpenLDAP to segfault. Is this possible? How would I do it? Do I need to remove all entries currently referencing the schema? Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

2 1

Whenchanged or modifyTimestamp filter
by Sébastien MALHEIRO 06 Aug '13

06 Aug '13

Hi, I want to configure openldap to work as a proxy for Active Directory. I have : A ldap database section to connect to active directory a dbd database to store local ldap A relay database to map Active Directory OU on a local OU This work fine but I have a problem with this type of filter : - ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(whenChanged>=20080812000000.0Z))" - ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(modifyTimestamp>=20080812000000.0Z))" => I have no result But with this type of filter : ldapsearch -x -D "cn=manager,dc=opencg21,dc=priv" -W "(&(objectClass=*)(uid=MyUsername))" => I can see the whenChanged and modifyTimestamp attributes. Can someone help me? I don't know how to have an error code to see where is the pb Thanks a lot. ---------------------------------------------- here is my slapd.conf -------------------------------------------- # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/microsoft-minimal.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la moduleload back_ldap moduleload rwm # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=opencg21,dc=priv" read by * none ############################################################ #LDAP ############################################################ database ldap suffix "OU=MYOU,DC=MYDC,DC=PRIV" uri ldap://mydc.cg21.priv rebind-as-user acl-bind bindmethod=simple binddn="CN=****,DC=PRIV" credentials="***" idassert-bind bindmethod=simple binddn="CN=****,DC=PRIV" credentials="***" mode=none lastmod on idassert-authzFrom * access to * by * read ############################################################ #RELAY ############################################################ database relay suffix "ou=myOU,dc=openldap,dc=priv" relay "ou=myOU,dc=mydc,dc=priv" subordinate overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteRule "(.+,)?ou=myOU,dc=openldap,dc=priv$" "$1ou=myOU,dc=mydc,dc=priv" ":" rwm-rewriteContext searchEntryDN rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=openldap,dc=priv$" "$1dc=openldap,dc=priv" ":" rwm-rewriteContext searchFilter rwm-rewriteContext referralAttrDN rwm-rewriteContext referralDN rwm-map attribute uid sAMAccountName rwm-map attribute modifyTimestamp modifyTimestamp #rwm-map objectclass inetOrgPerson * rwm-map objectclass groupOfNames group rwm-normalize-mapped-attrs yes ############################################################# #DATABASE PRINCIPALE ############################################################ database bdb suffix "dc=openldap,dc=priv" checkpoint 1024 15 rootdn "cn=Manager,dc=openldap,dc=priv" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}qGb9L/sewV24o10bQNynt3Kb2Uyv0Ac8 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap lastmod on # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub #index samaccountname # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM Ce message (pièces jointes comprises) est protégé par des règles relatives au secret des correspondances ; il peut en outre contenir des informations à caractère confidentiel ; il est établi à destination exclusive de son destinataire. Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce message, ou des informations qu'il contient, doit être préalablement autorisée. Tout message électronique est susceptible d'altération et son intégrité ne peut être assurée. Le Conseil Général de la Côte d'Or décline toute responsabilité au titre de ce message, s'il a été modifié ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur de l'erreur de distribution et de la destruction du message. Toute opinion contenue dans ce message appartient à son auteur : pour qu'il engage la responsabilité de l'institution, il doit être confirmé par un écrit et son auteur doit être dûment habilité.

1 0

Re: add rich data into attribute type definition possible?
by Ulrich Windl 06 Aug '13

06 Aug '13

Sorry, the list doesn't set the proper reply-to, so I forgot to send to the list... See attached message

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical