Hi,
I have being trying to solve this for more than a month. I installed Openldap, Samba, smbldap-tools, and phpmyadmin in a Red Hat 5.6 server. I have many users created with smbldap-tools.
Almost everything works, there are 2 things that I need help with.
One is with phpldapadmin. I can log with the user administrator, but can not change anything, this is the error in phpldapadmin
Could not perform ldap_modify operation.
LDAP said: Insufficient access
Error number: 0x32 (LDAP_INSUFFICIENT_ACCESS)
Description: You do not have sufficient permissions to perform that operation.
This error on the log
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 fd=11 ACCEPT from IP=127.0.0.1:59487 (IP=0.0.0.0:389)
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 BIND dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec" method=128
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 BIND dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec" mech=SIMPLE ssf=0
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 RESULT tag=97 err=0 text=
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 MOD dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec"
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 MOD attr=loginShell
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 RESULT tag=103 err=50 text=
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=2 UNBIND
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 fd=11 closed
This is my slapd.conf
############################################
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.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 /usr/lib64/openldap
# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# 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!
#access to *
# by self write
# by users read
# by anonymous auth
#access to attrs=userpassword
# by self =xw
# by anonymous auth by anonymous auth
#access to *
# by self write
# by users read
#access to attrs=userpassword by self write by anonymous auth by * none
#access to * by self write by users read by anonymous read by * none
#access to * by uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec write
#access to dn.regex = "ou = personal_addressbook or =(.+),, dc = korrigan, dc = org"
#by dn.regex="cn=$1,ou=Users,dc=korrigan,dc=org" write by dn.regex = "cn = $ 1, ou = Users, dc = korrigan, dc = org" write
#by dn="cn=admin,dc=korrigan,dc=org" write by dn = "cn = admin, dc = korrigan, dc = org" write
#by * none by * none
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=mydomain,dc=com,dc=ec"
rootdn "cn=Manager,dc=mydomain,dc=com,dc=ec"
# 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}XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# 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
# 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
# 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
# Extras para ser servidor master de ldap
loglevel 256
(I already posted this once)
##########################################3
When i add this line
access to * by self write by users read by anonymous read by * none
Users are allowed to change their info. I just want a group of users that can change the info of other users, users that have more privileges .
I also tried adding a group called miniadmins, it didnt work.
dn: cn=MiniAdmins,ou=People,dc=mydomain,dc=com,dc=ec
objectClass: groupOfNames
objectClass: top
cn: MiniAdmins
member: uid=jdc,ou=People,dc=mydomain,dc=com,dc=ec
member: uid=user2,ou=People,dc=mydomain,dc=com,dc=ec
structuralObjectClass: groupOfNames
entryUUID: a3e66d90-19b0-1030-9c61-73ebddf12515
creatorsName: cn=Manager,dc=mydomain,dc=com,dc=ec
modifiersName: cn=Manager,dc=mydomain,dc=com,dc=ec
createTimestamp: 20110523174841Z
modifyTimestamp: 20110523174841Z
entryCSN: 20110523174841Z#000012#00#000000
with the following acl
access to *
by group/groupOfNames/member="cn=MiniAdmins,ou=People,dc=iess,dc=gob,dc=ec" write
Also for the second part I dont know if you are able to do this with openldap: All users are part of dn: cn=Domain Users,ou=Group,dc=mydomain,dc=com,dc=ec. Also this users belong to others groups like city1, city2, city3. In each city there is and admin that has control over that group, example admincity1, admincity2,etc. They can manage users in their respective cities, but they can not change anything on another city.
I need help with the slapd.conf, I have a basic understanding, but my logic here is failing.
I have found people with similar problems but no answers.
Thanks,
Juan Diego
I came in late on this thread, so disregard if this has already been
said or is not applicable. Also, we use standard RH packages, so if you
are building your own, this may not be any use to you.
We have a few RH6 boxes authenticating against our ldap servers. It's
been awhile, but in addition to the CA certs being copied to the clients
and the correct perms assigned we had come success enabling legacy mode
in RH6 when running authconfig to set up the box. If I recall, in
legacy mode sssd does not run and it uses a more RH5 way of
authenticating clients. Unfortunately, I don't have a RH6 box in front
of me, but you can edit /etc/sysconfig/authconfig to set legacy mode.
Then run your authconfig command to set up the box. Also, look at
/etc/pam_ldap.conf if you decide to try to authenticate in this manner.
The settings in there are like they were in /etc/ldap.conf, RH5. Your
system-auth file looks like ours does as far as I can remember.
Just something else you may want to try if you haven't already.
On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya" <jflo(a)imppc.org>
wrote:
> Hello,
>
> After doing all you suggest with the pki keys I'm stuck in the very same
> place, the system is able to do ldapsearch but all user auth is not
> working, I do this in order to configure the auth in the clients
> # authconfig --disablecachecreds --enableldaps --enableldapauth
> --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
> --disablefingerprint --disablewinbind --disablewins --disablesssd
> --disablesssdauth --disablenis --enablecache --enablelocauthorize
> --disablemd5 --passalgo=sha512 --updateall
>
>
> The pam.d files look ok:
>
> # cat /etc/pam.d/system-auth
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth required pam_env.so
> auth sufficient pam_unix.so nullok try_first_pass
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth sufficient pam_ldap.so use_first_pass
> auth required pam_deny.so
>
> account required pam_unix.so broken_shadow
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account required pam_permit.so
>
> password requisite pam_cracklib.so try_first_pass retry=3 type=
> password sufficient pam_unix.so sha512 shadow nullok
> try_first_pass use_authtok
> password sufficient pam_ldap.so use_authtok
> password required pam_deny.so
>
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session [success=1 default=ignore] pam_succeed_if.so service in
> crond quiet use_uid
> session required pam_unix.so
> session optional pam_ldap.so
>
> This is the message in ldap server when I do id <ldap_user>
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
> IP=[::1]:36208 (IP=[::]:636)
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
> tls_ssf=256 ssf=256
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
> oid=1">oid=1.3.6.1.4.1.1466.20037
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
> text=TLS already started
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
>
> Aparently is ok but the id is not known
> Any ideas?
> Thanks a lot!
> j
>
> On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
> > Hello Aaron,
> >
> > On 04/13/2011 09:07 PM, Aaron Richton wrote:
> >> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
> >>
> >>> I see, I also have those files that you mention... I created my own CA
> >>> as lots of tutorials explain.. Then I transmitted it to the clients and
> >>> used it in the ldap.conf file. Do you suggest me to send those to the
> >>> server and use them instead of the ones I generated with openssl?
> >>
> >> Well, you'll need the CA on the client to match the CA that signed the
> >> server's certificate. In other words...if you generated your own CA for
> >> both the client and the server, trust issues would be completely
> >> expected...
> > I don't know if I understood you or I didn't make myself clear on that
> > point. I created a CA in the server and the copied the file to the
> > client, is that wrong?
> >>
> >>> What's your server?
> >>
> >> OpenLDAP software is on both sides of the equation; it's just that some
> >> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
> >> ALL servers are OpenSSL.
> > I was talking about the operating system, for some reason I think that
> > having red hat (with openldap compiled using openssl) and clients with
> > fedora (openldap compiled against moznss) created my problems.
> > Now that you said that this is your case (I think) then it may be
> > something related to... I don't know what.
> >>
> >>> Well my final problem were not ldapsearch but the user autenticacion.
> >>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
> >>> with an ldap user to the machine, I get some TLS negotiation problem ;(
> >>> That's when I was told that the problem may be caused by the
> >>> implementation of the ldap client (with moznss support).
> >>
> >> Well, when troubleshooting, it's often easiest to look with a narrow
> >> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
> >> will probably offer a better debugging platform than an ssh
> >> implementation? One step at a time...
> > Yes, I totally agree, that's why I setup my own openldap installation
> > and only care about ldapsearch working, then when ldapsearch finally
> > worked, then I start looking at the user auth part, changing passw,
> > etc.. as this part wasn't working and it appear to be a moznss problem,
> > I got stuck... until you arrived, I will try what you suggest about
> > using the pki certs instead of the openssl ones..
> >
> > Thanks a lot for the suggestion, hope this finally fix the issue.
> > j
>
> --
> Judith Flo Gaya
> Systems Administrator IMPPC
> e-mail: jflo(a)imppc.org
> Tel (+34) 93 554-3079
> Fax (+34) 93 465-1472
>
> Institut de Medicina Predictiva i Personalitzada del Càncer
> Crta Can Ruti, Camí de les Escoles s/n
> 08916 Badalona, Barcelona,
> Spain
> http://www.imppc.org
>
>
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é.
Chris Jackson wrote:
> On Feb 16, 2011, at 3:46 AM, <harry.jede(a)arcor.de>
>
> <harry.jede(a)arcor.de> wrote:
> > Chris Jackson wrote:
> >> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
> >>
> >> Is it possible to prevent anonymous and unauthenticated binds to
> >> ldaps:// 636 but allow them on ldap:// 389?
> >>
> >> I want to allow staff to query my ldaps:// outside of my network
> >> while requiring them to login to do so but allow anyone to bind
> >> (anonymous, unauthenticated, or authenticated) internally on
> >> ldaps//: 389.
> >>
> >> I know:
> >> Anonymous bind can be disabled by "disallow bind_anon" and
> >> Unauthenticated bind mechanism is disabled by default. But if I
> >> use "disallow bind_anon it stops in on both ports.
> >
> > Sure, this are global directives.
> >
> >> I want to stop it just on ldaps://.
> >
> > You don't need ldaps:// in your local network? May be.
> > I think a easier solution is to identify your Internet Gateway by
> > IP.
> >
> >> Chris Jackson
> >>
> >>
> >> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
> >>
> >> Stopping users that are "unauthenticated" makes no sense;
> >> everything's unauthenticated at time=0. You might as well stop
> >> slapd if you want a 100% inability to serve data.
> >>
> >> You can deny anonymous users that aren't plaintext, including any
> >> ldaps:/// connections, with something like:
> >>
> >> access to *
> >> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
> >> by anonymous none
> >>
> >> early on in your ACL stanzas. I'm pretty sure this'll deny
> >> anonymous StartTLS users on 389, though; not sure if that's what
> >> you want. I can't think of any way to use the slapd access
> >> language to differentiate based on listeners, which would probably
> >> be the most elegant way to handle what you asked. To be fair, this
> >> entire exercise seems really odd from where I sit -- are you
> >> positive that this will have the desired effect? (If somebody out
> >> in Peru is permitted to connect in unencrypted and make anonymous
> >> queries, why not allow them to make those same queries encrypted?
> >> What's the difference?)
> >>
> >> here is a scenario:
> >>
> >> Site has a ldap server on ldap://389. Firewall blocks access to
> >> 389 from internet. Everyone queries the ldap via anonymous binds.
> >> Site would like to allow staff the ability to query the ldap
> >> from outside the firewall. This would be done via ldaps:// 636 to
> >> users who have authenticated via username/password. They do not
> >> want to allow anonymous queries outside the firewall.
> >>
> >> Using the "disallow bind_anon" would prevent anon binds on both
> >> ldap:// and ldaps://. This would break the inside machines
> >> ability to query. If we dont use "disallow bind_anon" then
> >> machines outside of the firewall could query the ldap.
> >>
> >> ---Is the only option for them to setup two separate ldap servers?
> >
> > No. You should use ACLs to solve this problem. Read man
> > slapd.access an/or search the openldap archives.
> >
> > Assuming you have a NAT gatway as Firewall machine.
> >
> > Replace all "by anonymous" statements with these 6 statements:
> >
> > by anonymous auth continue
> > by peername.ip="127.0.0.1" read continue
> > by peername.ip="10.0.0.0%255.0.0.0" read continue
> > by peername.ip="172.16.0.0%255.240.0.0" read continue
> > by peername.ip="192.168.0.0%255.255.0.0" read continue
> > by peername.ip="gateway-ip" auth
> >
> > One may write these statements more effective, but in general they
> > will do.
> >
> >
> > Replace "gateway-ip" with yours.
> >
> > Put the above statements also in every ACL just before the
> > by *
> > when this ACL do NOT have an "by anonymous" statement.
> >
> > Maybe the last line could/should be:
> > by ssf=56 peername.ip="gateway-ip" auth
> >
> > Caveats:
> > Your gateway can no longer access your LDAP Server with
> > the "gateway-ip". But this is a Firewall Design Question.
> >
> > I've tested this only with unencrypted sessions; anoymous and
> > authenticated. But TLS or SSL will not grant more rights, if you do
> > not tell the ACLs to do so.
> >
> >
> > Here the output from the two searches:
> >
> > # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
> > Insufficient access (50)
> >
> > # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
> > cn=admin,dc=kronprinz,dc=xx -W
> > dn: dc=kronprinz,dc=xx
> >
> > dn: cn=admin,dc=kronprinz,dc=xx
> >
> >> One with "disallow bind_anon" and one without. Then only open the
> >> firewall for port 636 to the ldap server which has "disallow
> >> bind_anon".
> >>
> >> Chris Jackson
> >
> > --
> >
> > Harry Jede
>
> The above example got me started in the right direction.
fine, but have you read "man slapd.access"?
> Everything appears to be doing exactly what I wanted to do.
I can not believe.
> I did notice that
> the anonymous bind users from ip addresses not 10, give an error 32.
> Anyone see any flaws in this?
When you got errors, then something must be wrong.
> The below ACL should be allowing anon binds when ip address is
> 10.*.*.* or allow authenticated binds from any ip address.
>
>
access to attrs=userpassword
by anonymous auth
by self read
by * none
access to *
by anonymous auth continue
by peername.ip="10.0.0.0%255.0.0.0" read
by users read
by * none
This looks better. ACLs are evaluated in order. The continue clause
extends the current line with the folloing line. So both are just one
ACL statement.
This is OK:
by anonymous auth continue
by peername.ip="10.0.0.0%255.0.0.0" read
This is bad:
by anonymous auth continue
by users read
Here you try to extend anonymous with users; which will not work.
BTW
These ACLs does not allow any user to change his password by himself.
> Chris
--
Harry Jede
Diego Morales wrote:
> Hello,
>
> I have a proprietary windows application trying to bind on my OpenLDAP
> server using GSSAPI with NTLMSSP mechanism, instead of Kerberos. Is it
> possible to support this on a (unix) OpenLDAP server?
Yes, but this has nothing to do with OpenLDAP software. All of SASL/GSSAPI is
handled by the Cyrus SASL library. The Cyrus GSSAPI implementation depends on
the underlying GSSAPI library, which may be provided by MIT Kerberos or
Heimdal Kerberos. The Heimdal library definitely supports GSSAPI/NTLMSSP, I'm
not sure if the MIT library does or not.
It sounds like your installation is not using Heimdal.
> Another option would be to make the software use GSSAPI + Kerberos
> instead. Let me further explain:
>
> I have a working samba + openldap setup with many windows
> workstations. The said proprietary app has LDAP auth support, and
> according to its maker it works with Active Directory and Novell NDS.
> It does not support simple bind, nor LDAPS, (and probably not StartTLS
> either). We don't have access to the app's source code and help from
> its developers/tech-support is pretty unavailable.
>
> Checking slapd's debug, we saw the app trying to use SASL+GSSAPI to
> bind. So we went on and configured a minimal Kerberos setup and
> SASL+GSSAPI support for OpenLDAP on a test ldap server. It seems to be
> working perfectly. We acquire a ticket and run ldapsearch from another
> machine using -Y GSSAPI bind and it works. Logs from slapd debug seem
> ok.
>
> But that evil app still fails. Here's a piece from slapd debug log:
>
> conn=1000 op=1 do_bind
> ber_scanf fmt ({imt) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8813 end=0x7f73f6af8856 len=67
> 0000: 60 84 00 00 00 3d 02 01 03 04 00 a3 84 00 00 00 `....=..........
> 0010: 32 04 06 47 53 53 41 50 49 04 28 4e 54 4c 4d 53 2..GSSAPI.(NTLMS
> 0020: 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 SP..............
> 0030: 00 00 00 00 00 00 00 00 00 00 00 06 01 b1 1d 00 ................
> 0040: 00 00 0f ...
> ber_scanf fmt ({m) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af881e end=0x7f73f6af8856 len=56
> 0000: 00 84 00 00 00 32 04 06 47 53 53 41 50 49 04 28 .....2..GSSAPI.(
> 0010: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 NTLMSSP.........
> 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0030: 06 01 b1 1d 00 00 00 0f ........
> ber_scanf fmt (m) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af882c end=0x7f73f6af8856 len=42
> 0000: 00 28 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 .(NTLMSSP.......
> 0010: 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0020: 00 00 06 01 b1 1d 00 00 00 0f ..........
> ber_scanf fmt (}}) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8856 end=0x7f73f6af8856 len=0
>
>>>> dnPrettyNormal: <>
> <<< dnPrettyNormal: <>, <>
> conn=1000 op=1 BIND dn="" method=163
> do_bind: dn () SASL mech GSSAPI
> ==> sasl_bind: dn="" mech=GSSAPI datalen=40
> SASL [conn=1000] Failure: GSSAPI Error: An unsupported mechanism was
> requested (Unknown error)
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_result: err=49 matched="" text="SASL(-13): authentication
> failure: GSSAPI Failure: gss_accept_sec_context"
> send_ldap_response: msgid=11 tag=97 err=49
> ber_flush2: 87 bytes to sd 13
> 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
> 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
> 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
> 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
> 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
> 0050: 63 6f 6e 74 65 78 74 context
> ldap_write: want=87, written=87
> 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
> 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
> 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
> 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
> 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
> 0050: 63 6f 6e 74 65 78 74 context
> conn=1000 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication
> failure: GSSAPI Failure: gss_accept_sec_context
>
> (btw, this is slapd 2.4.21, from a 10.04 ubuntu package)
>
> I believe the application uses Windows SSPI, and I known SSPI supports
> several GSSAPI mechanisms, including NTLMSSP and Kerberos. I'm afraid
> Windows is auto selecting NTLMSSP cause its running on a pre-windows
> 2000 domain (non AD, in this case, Samba). Hoping to make windows use
> Kerberos instead, I've also tried publishing some SRV records on DNS.
> I have sniffed DNS queries from the workstation while the app tries to
> login, caught only one _ldap._tcp SRV request, registered that ... and
> nothing has changed.
>
> I don't know how could I force the app to use GSSAPI + kerberos
> without touching its source code. And I can't find much about a unix
> NTLM(SSP)-as-a-mechanism-of-GSSAPI implementation. Maybe there's
> something inside samba4 or in Likewise software, but I haven't found
> it yet.
>
> So ... does somebody have any advice or info?
>
> Thanks in advance,
>
>
> Diego Morales
> +55 (51) 3024-3568
> Propus Informática LTDA.
> http://www.propus.com.br
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
I have modified my slapd.conf file on consumer 2.4
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
#include /usr/share/doc/krb5-server-ldap-1.9/kerberos.schema
#include /usr/share/doc/sudo-1.8.5-1.el6/schema.OpenLDAP
# Primary database.
database bdb
directory /var/lib/ldap
suffix "dc=kinect,dc=co,dc=nz"
rootdn "cn=Manager,dc=kinect,dc=co,dc=nz"
rootpw {SSHA}vO/5mpk4CMOKDelv36BpjksRaHFjgqh1
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# syncrepl specific indices
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 entryUUID eq
index entryCSN eq
# syncrepl directives
syncrepl rid=3
provider=ldap://testaaa-int.dcnztest.co.nz:389
bindmethod=simple
starttls=no
binddn="cn=sync,dc=kinect,dc=co,dc=nz"
credentials="ieLeik8v"
searchbase="dc=kinect,dc=co,dc=nz"
logbase="cn=accesslog"
schemachecking=off
type=refreshAndPersist
retry="05 +"
syncdata=accesslog
# Refer updates to the master
updateref ldap://testaaa-int.dcnztest.co.nz
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
access to attrs=userPassword by self write by * auth
access to dn.base=dc=kinect,dc=co,dc=nz by * search
by * none
# Give access to this database to serveral important users.
#to dn.subtree="dc=kinect,dc=co,dc=nz"
access to attrs=userPassword
by dn.exact="cn=sync,dc=kinect,dc=co,dc=nz" read
by dn.exact="uid=client-root,ou=auth,dc=kinect,dc=co,dc=nz" write
by self write
by anonymous auth
by * none
# default allow all
access to *
by self write
by users read
by anonymous read
TLSCACertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateKeyFile /etc/openldap/tls/test02aaa-key.pem
database monitor
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none
# Configure the config backend.
database config
# Again, let SASL EXTERNAL users with UID 0 & GID 0 users and the rootdn
manage
# the configuration. But not any other users.
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none
Then run
#slapcat -f ldap/slap.conf.consumer -F /tmp/ldap -n 0
#cp -rp ldap/cn\=config* /etc/openldap/slapd.d/
#chown -R ldap:ldap /etc/openldap/slapd.d
#slaptest -uF /etc/openldap/slapd.d
#/etc/init.d/slapd start
Now it comes up with a different error
Mar 20 11:52:31 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:31 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
This is the value of objectclass in /etc/openldap/slapd.d/
/root@vm-nix-t01 tmp]# grep -iR objectclass /etc/openldap/slapd.d/*
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass:
olcDatabaseConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass:
olcBdbConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif: objectclass=*)"
searchbase="dc=kinect,dc=co,dc=nz" logbase="cn=accesslog" sco
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:olcDbIndex:
objectClass pres,eq
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:structuralObjectClass:
olcBdbConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:objectClass: olcSchemaConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmObjectClasses 1.3.6.1.4.1.4203.666.3.16
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmSubSystemObjectClasses olmObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmGenericObjectClasses olmSubSystemObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmDatabaseObjectClasses olmSubSystemObjectClasses:1
Any suggestions
On 18 March 2014 18:40, Philip Guenther <pguenther(a)proofpoint.com> wrote:
> On Mon, 17 Mar 2014, Andrew Belford wrote:
> > I have just registered on the mail list seeking for assistance of how to
> > get openldap replication working between 2.3 and 2.4 openldap.
>
> Time to read the "Changes Since Previous Release" section of the 2.4 admin
> guide:
> http://www.openldap.org/doc/admin24/appendix-changes.html
>
>
> > My provider is running on 2.3(openldap) which replicates successfully
> > to a 2.3(openldap slave). Recently we build a rhel6 host that comes
> > with openldap 2.4 with the intention to run openldap on it as slave.
> >
> > I have stand up the new slave(2.4 openldap) using the same configuration
> of
> > the other running slave(2.3openldap)
> > I have managed to slapadd the ldif of the master to the new slave
> > slapadd -l /tmp/AAA01_20140314.ldif
> >
> > However, if I try and search for entries, it shows the following but I am
> > expecting 32K objects
>
> Item B.2 at
> http://www.openldap.org/doc/admin24/appendix-upgrading.html
> ?
>
>
> > I also don't see any replication details in /var/log/slapd.log
>
> Since you don't mention how you configured replication to this 2.4 box or
> what output you were expecting, I can't help on this.
>
>
> Philip Guenther
>
Hi,
Not sure if I should post this here or with the CentOS mailing list (I am hoping
they are monitoring this). I am using a stock CentOS 6.3 32-bit installation
with
# rpm -qa | grep openldap
openldap-devel-2.4.23-26.el6_3.2.i686
openldap-2.4.23-26.el6_3.2.i686
openldap-clients-2.4.23-26.el6_3.2.i686
openldap-servers-2.4.23-26.el6_3.2.i686
I have a 4-way multi-master sync replication set up on four virtual servers
using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one
machine and BDC on the other three. All servers are also running sssd-1.8.0 for
the Linux authentication.
The problem is that one or more of the LDAP servers will hang, usually the one
that acts as the PDC, since this is hit the hardest and is the more critical of
the four. Usually but not always the "hang" will trickle to the other
servers--usually when I am not watching during the middle of the night.
Fortunately we are not yet in full production.
Compiling from source is not yet an option. I must use the stock RPMs from
CentOS per our design guidelines.
LDAP will appear to hang but what appears to be happening is that only the
listener becomes busy and will not get out this state. Here is a short pull of
the logs that I am collecting:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text=
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]: 69r
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]: 39r
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:12 auth-us slapd[10357]: 42r
Aug 14 20:35:12 auth-us slapd[10357]:
Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:14 auth-us slapd[10357]: 40r
Aug 14 20:35:14 auth-us slapd[10357]:
Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Every log entry prior to this looks normal in that epoll: listen=7 goes between
active_threads=0 to busy when a connection comes in, sets up the connection, and
then goes back to active_threads=0. I have yet to understand what is going on to
cause it to go into the busy state and never to return until I manually stop and
restart the slapd process. It does appear however that slapd can still process
any queries on active connections as noted on descriptors 40r and 42r--it just
can't process any new connection requests as epoll: listen=7 has hung.
Looking through the archives this problem still appears to be present in a few
additional later releases but I have not found any thread yet which points to a
specific solution or patch that fixes this problem. Unless I can point to a
specific solution and/or patch I won't get approval to do a pull from the latest
source and compile--I'll have to stick with an hourly cron job that stops and
restart slapd.
Thanks,
Bob Smith
--bs
2013/2/28 Jimmy Royer <jimmy.royer(a)modelsolv.com>:
> Hello,
>
> I am starting out with openldap and I don't know it that much. I got
> the error mentioned in the title when trying to add an object class,
> which is apparently a very common one per my google searches. I've
> read that common causes are:
>
> * extraneous white space (especially trailing white space)
> * improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
> * empty values (few syntaxes allow empty values)
>
> This is the object class file I am trying to add, I picked it as an
> example on some website, to have something minimal and make it easier
> to test:
>
> # cat exObjectClasses.ldif
> dn: cn=schema
> changetype: modify
> add: objectClasses
> objectClasses: ( 2.16.840.1.113730.3.2.2.9
> NAME 'blogger'
> DESC 'Someone who has a blog'
> SUP inetOrgPerson STRUCTURAL
> MAY blog )
>
> I've checked if there was any trailing spaces at the end with the following:
>
> # cat -vte exObjectClasses.ldif
> dn: cn=schema$
> changetype: modify$
> add: objectClasses$
> objectClasses: ( 2.16.840.1.113730.3.2.2.9$
> NAME 'blogger'$
> DESC 'Someone who has a blog'$
> SUP inetOrgPerson STRUCTURAL$
> MAY blog )$
>
> I've made sure the file is UTF-8:
>
> # iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
>
> And I don't think there are any empty values defined in the LDIF file.
> So when I type this command, I still have the "invalid per syntax
> error:
>
> # ldapmodify -x -W -H "ldaps://127.0.0.1" -D
> cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif
> Enter LDAP Password:
> modifying entry "cn=schema"
> ldap_modify: Invalid syntax (21)
> additional info: objectClasses: value #0 invalid per syntax
>
> This is the content of the /etc/openldap/slapd.conf file:
>
> # cat 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
>
> # 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
>
> # 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=my-domain,dc=com" read
> by * none
>
> #######################################################################
> # database definitions
> #######################################################################
>
> database bdb
> suffix "dc=modelsolv,dc=com"
> checkpoint 1024 15
> rootdn "cn=Manager,dc=modelsolv,dc=com"
> # Cleartext passwords, especially for the rootdn, should
> # be avoided. See slappasswd(8) and slapd.conf(5) for details.
> # Use of strong authentication encouraged.
> rootpw SECRET
> # rootpw {crypt}ijFYNcSNctBYg
>
> # 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
>
> # 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
>
> # 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
>
>
> I was able to add a few entries in LDAP so far. So I know I am able to
> reach the server, the connection is fine, and LDAP is somewhat
> functional. But I can't modify the schema with objectclasses.
>
> Is there anything obvious that I am doing wrong? Do you have any
> recommendation for debugging further?
>
Hi,
you can't update schema by acting on cn=subschema branch, this is readonly.
As your are using the old slapd.conf file, you need to create a
.schema file and include it in slapd.conf.
If you want to update schema with LDIF file, change from slapd.conf to
cn=config configuration method.
Clément.
> Regards,
> Jimmy Royer
>