User-Managed Groups
by Tim Gustafson
Hi,
I've had OpenLDAP set up for a while now such that users can create
groups and manage the groups that they've created. I've achieved this
by creating a new objectClass (called "managedGroup") which adds the
"manager" attribute, and then I've set up ACLs like this:
olcAccess: {14}to dn.base="ou=Groups,dc=whatever"
attrs=children
by users add
by * break
olcAccess: {15}to dn.subtree="ou=Groups,dc=whatever"
filter="(&(objectClass=posixGroup)(objectClass=managedGroup)(gidNumber>=1000))"
attrs=entry
by users add
by * break
olcAccess: {16}to dn.subtree="ou=Groups,dc=whatever"
attrs=cn,manager,memberUid,description
by set.exact="this/manager & user" write
by * break
I also have the "unique" overlay installed to prevent multiple groups
from having the same "cn" or "gidNumber".
I've got a request from users to be able to re-name their groups now
too. I tried changing "by users add" to "by users write" in clause
14, and added the "entry" attribute to "attrs=" in clause 16, but the
server is still not letting users re-name their groups. The output of
the log file looks like this:
slapd[44745]: => acl_get: [16] attr entry
slapd[44745]: => acl_mask: access to entry
"cn=test-1234,ou=Groups,dc=whatever", attr "entry" requested
slapd[44745]: => acl_mask: to all values by
"uid=g-guest,ou=people,dc=whatever", (=0)
slapd[44745]: <= check a_dn_pat: users
slapd[44745]: <= acl_mask: [1] applying add(=arscxd) (stop)
slapd[44745]: <= acl_mask: [1] mask: add(=arscxd)
slapd[44745]: => slap_access_allowed: write access denied by add(=arscxd)
slapd[44745]: => access_allowed: no more rules
What am I missing?
--
Tim Gustafson
tjg(a)ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
9 years, 3 months
Help with trying to setup RE: Issues with setting up multiple master
by Alex Samad - Yieldbroker
Hi
Any one got any hints at what I can look at to fix this ?
Alex
> -----Original Message-----
> From: Alex Samad - Yieldbroker
> Sent: Wednesday, 5 March 2014 4:11 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Issues with setting up multiple master
>
> Hi
>
> So I am setting up multi master following the steps here
> http://www.openldap.org/doc/admin24/replication.html 18.3.3
>
> I have 2 nodes and not 3.
>
> I did this on the master
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 1
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
> and on the 2nd
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 2
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
>
>
> I used a different password on each site . changed it to the same password
> no
>
>
> I did this
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 $URI1
> olcServerID: 2 $URI2
>
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcSyncRepl
> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"
> bindmethod=simple
> credentials=secret searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config"
> bindmethod=simple
> credentials=secret searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
>
> I am wondering why I did
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 2
>
> if I am just going to do this
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 $URI1
> olcServerID: 2 $URI2
>
> This is what I get on the second node
> Mar 5 16:08:09 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD
> Mar 5 16:08:09 alcldap1 slapd[21296]: do_syncrepl: rid=001 rc -1 retrying (4
> retries left)
> Mar 5 16:08:14 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD
> Mar 5 16:08:14 alcldap1 slapd[21296]: do_syncrepl: rid=001 rc -1 retrying (4
> retries left)
> Mar 5 16:08:19 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD
>
>
> And on the first node
> Mar 5 16:09:27 gsldap1 slapd[11028]: do_syncrep2: rid=002 got empty
> syncUUID with LDAP_SYNC_ADD
> x
> Mar 5 16:09:27 gsldap1 slapd[11028]: do_syncrepl: rid=002 rc -1 retrying (4
> retries left) x
>
> I have done manual ldapsearch from both boxes to the other boxes with the
> credentials and it works
>
>
> So now I am stuff. Had a quick google, but could find anything relevant.
>
> Help :)
>
> Oh I started with info in the db's already. Just a rsync ...
>
> Alex
>
>
>
9 years, 3 months
Slapd TLS issue
by Eric Falbe
Hi,
When I try to start slapd I get this error message:
Checking configuration files for slapd: [WARNING]
PROXIED attributeDescription "DC" inserted.
config file testing succeeded
Starting slapd: @(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $
mockbuild(a)c6b10.bsys.dev.centos.org:
/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
PROXIED attributeDescription "DC" inserted.
bdb_db_open: database "dc=cassens,dc=com": unclean shutdown detected;
attempting recovery.
bdb_db_open: database "cn=accesslog": unclean shutdown detected; attempting
recovery.
slapd starting
TLS: error: the certificate '/etc/pki/tls/certs/ldap.cassens.com.pem' could
not be found in the database - error -12285:Unable to find the certificate
or key necessary for authentication..
TLS: certificate '/etc/pki/tls/certs/ldap.cassens.com.pem' successfully
loaded from PEM file.
TLS: no unlocked certificate for certificate 'CN=ldap.cassens.com,OU=Ldap
Server,O=Cassens Transport Company,C=US'.
ppolicy_bind: Setting warning for password expiry for
cn=replication,dc=cassens,dc=com = 0 seconds
^Cdaemon: shutdown requested and initiated.
slapd shutdown: waiting for 0 operations/tasks to finish
slapd stopped.
This server was working last night, I had to promote our secondary ldap
server this morning.
I have attempted to rebuild the database backend (with slapcat and
slapadd), but am still getting this same error. I have my ssl
(self-signed) certificates located in
/etc/pki/tls/certs/ldap.cassens.com.pem /etc/pki/tls/tls/certa/ca.pem
/etc/pki/tls/private/ldap.cassens.comKey.pem
These certificates worked fine up untill today, does anyone have any
insight on where to look to being troubleshooting this issue?
Thanks,
Eric Falbe
9 years, 3 months
Documentation required on openldap 2.4.39
by saurabh ohri
Hi,
Does anyone installed openldap 2.4.39 or later. Please help me with self created document as i am getting stuck at various point.
I have installed and configured but not able to :
1) Change the ldap to work for ldap(389) to ldaps(636) with openssl certs.
2) Not able to convert the slapd.conf to config.
3) Implementing password policies.
4) 2 node Replication Master-Master
Please help as it is been 2 weeks and am dead stuck. Project completion data is near so quick help will be highly appreciated.
Thanks again
Regards
Sam
9 years, 3 months
LDAP Passwordless SSH Problem
by Kamran Khan
Hi all,
I have a cluster, running RHEL6.5, which I have installed and configured LDAP w/ TLS support. The systems are all authenticating using LDAP properly, and I have added a test user to make sure this works. I can 'su' into the new user, and SSH across all systems. However, it requires a password upon every SSH.
Please see verbose SSH below:
===================================================
[root@usdtwclus01 ~]# su - jramey
[jramey@usdtwclus01 ~]$ ssh -vvvvv n001
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to n001 [172.16.36.1] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/jramey/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/jramey/.ssh/id_rsa type 1
debug1: identity file /home/jramey/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 5 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 960 bytes for a total of 981
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib(a)openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib(a)openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib(a)openssh.com
debug2: kex_parse_kexinit: none,zlib(a)openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 1005
debug2: dh_gen_key: priv key bits set: 120/256
debug2: bits set: 522/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 1149
debug3: check_host_in_hostfile: host n001 filename /home/jramey/.ssh/known_hosts
debug3: check_host_in_hostfile: host n001 filename /home/jramey/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: host 172.16.36.1 filename /home/jramey/.ssh/known_hosts
debug3: check_host_in_hostfile: host 172.16.36.1 filename /home/jramey/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'n001' is known and matches the RSA host key.
debug1: Found key in /home/jramey/.ssh/known_hosts:1
debug2: bits set: 504/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 1165
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1213
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jramey/.ssh/id_rsa (0x7f0a9fb7a6a0)
debug3: Wrote 64 bytes for a total of 1277
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 172.16.36.1.
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_15000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_15000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_15000' not found
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jramey/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
jramey@n001's password:
===================================================
Any ideas on how to accomplish passwordless SSH with LDAP users?
Please let me know.
Thanks.
--
Kamran Khan
PSSC Labs
HPC Software Technical Engineer
9 years, 3 months
mirror mode & sasl question
by Eileen(=^ω^=)
Hi all，
This is Eileen from China SINAP. I am a beginner for openldap soft. I encountered a problem in my study on two LDAP services replication.
I have 2 LDAP services, one name LDPA1, the other is LDAP2 . I want to make them synchronously in mirror mode. But when I set LDAP services rootpw both in hash, the 2 LDAP serivces can’t be synchronous.
My question is
1. if I set my rootpw in hash, my bindmethod must be SASL? If I must use sasl method, can I put the sasl service in the same ldap service? If bindmethod=sasl then what is the saslmech should be?
2. If I change to sasl method, do I need change my database record?
My slapd.conf file set as below, could you pls advice which place I should fix?
moduleload syncprov.la
database bdb
suffix "dc=xxx,dc=xxx"
checkpoint 1024 15
rootdn "cn=xxx,dc=xxx,dc=xxx"
rootpw {SSHA}cXUVsI2kuKNK9kjCagWtvraossyAKuhX
directory /var/lib/ldap/xxx
access to *
by self write
by * read
# Indices to maintain for this database
index objectClass,entryCSN,entryUUID 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
serverID 1 (ldap2 service is 2)
syncrepl rid=111
provider=ldap://other side ip
bindmethod=sasl
saslmech=ssha
authcid=?
Authzid=?
Realm=?
binddn="cn=xxx,dc=xxx,dc=xxx"
credentials={SSHA}cXUVsI2kuKNK9kjCagWtvraossyAKuhX
searchbase="dc=xxx,dc=xxx"
schemachecking=on
type=refreshAndPersist
retry="60 +"
mirrormode on
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
My database record just like below:
dn: cn=tiangexuan,ou=users,dc=xxx,dc=xxx
cn: tiangexuan
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
sn: tiangexuan
uid: tiangexuan
uidNumber: 10001
gidNumber: 90001
homeDirectory: /home/tiangexuan
loginShell: /bin/bash
userPassword: calvin
Best wishes & regrads
Eileen
9 years, 3 months
Restricting access based on IP Address
by kevin sullivan
Hi,
I am running an OpenLDAP server version 2.4.23 and I would like to restrict
a user from connecting unless they are connecting via an ldapi connection
or localhost. Specifically, I would like to only let the rootdn manage
things from localhost or from an ldapi connection, which ensures that they
are on localhost. I do not want to prevent other users from connecting to
my LDAP server via an ldaps connection from anywhere on the network.
Is this possible? I have read a good bit about access control directives,
but I haven't seen what I am looking for. I am guessing that what I am
looking for probably deals with 'sockname' or 'sockurl', but I don't know
how to use those statements to properly configure slapd.
Thanks,
Kevin
9 years, 3 months
Issues with setting up multiple master
by Alex Samad - Yieldbroker
Hi
So I am setting up multi master following the steps here http://www.openldap.org/doc/admin24/replication.html 18.3.3
I have 2 nodes and not 3.
I did this on the master
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret
and on the 2nd
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 2
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret
I used a different password on each site . changed it to the same password no
I did this
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 $URI1
olcServerID: 2 $URI2
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
I am wondering why I did
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 2
if I am just going to do this
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 $URI1
olcServerID: 2 $URI2
This is what I get on the second node
Mar 5 16:08:09 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD
Mar 5 16:08:09 alcldap1 slapd[21296]: do_syncrepl: rid=001 rc -1 retrying (4 retries left)
Mar 5 16:08:14 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD
Mar 5 16:08:14 alcldap1 slapd[21296]: do_syncrepl: rid=001 rc -1 retrying (4 retries left)
Mar 5 16:08:19 alcldap1 slapd[21296]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD
And on the first node
Mar 5 16:09:27 gsldap1 slapd[11028]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD x
Mar 5 16:09:27 gsldap1 slapd[11028]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) x
I have done manual ldapsearch from both boxes to the other boxes with the credentials and it works
So now I am stuff. Had a quick google, but could find anything relevant.
Help :)
Oh I started with info in the db's already. Just a rsync ...
Alex
9 years, 3 months
ppolicy not working in 2.4.23 !!
by saurabh ohri
Hi All,
tried implementing the ppolicy on 2.4.23 version but it is not working. So i tried installing the upgraded version i.e 2.4.39 from source.but getting following error:
Mar 4 12:36:06 juc-dom1-prd slapd[5513]: @(#) $OpenLDAP: slapd 2.4.39 (Mar 4 2014 11:05:59) $#012#011root@juc-dom1-prd.j.cinglevue.com:/tmp/openldap-2.4.39/servers/slapd
Mar 4 12:36:06 juc-dom1-prd slapd[5513]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol)
Mar 4 12:36:06 juc-dom1-prd slapd[5513]: lt_dlopenext failed: (back_bdb.la) file not found
Mar 4 12:36:06 juc-dom1-prd slapd[5513]: slapd stopped.
Mar 4 12:36:06 juc-dom1-prd slapd[5513]: connections_destroy: nothing to destroy.
Previously was getting error:
Unrecognized database type (bdb) in openldap 2.4.39
In order to fix this i added below line in slapd.conf file:
moduleload back_bdb.la
Please help as implementing open ldap is getting crazy now.
regards
Sam
9 years, 3 months
