temporarily removing a group object in SLES11
by Ulrich Windl
Hi!
I realized that in SLES11 SP2 the YaST user management module does recreate a group (instead of modifying it) when you add a user to the particular group. I wonder what the consequences could be (despite of the unnecessary deltas being created). Did anybody else notice this, or even had some negative experience caused by that, escpecially for groups with many members?
Regards,
Ulrich
9 years, 11 months
Q: access rights for shadowAccount attributes
by Ulrich Windl
Hi!
I wonder what the minimum required access rights for the attributes of shadowAccount are: Should they be protected the same way the password is? At the moment an anonymous bind can read them (i.e. no special access rules present).
Regards,
Ulrich
9 years, 11 months
Need help with replica
by Jacques Foucry
Hello list,
I created a VM to test ppolicy migration and replication.
On my master server some user (like mine) are "bind" to ppolicy:
I have a OU policies
dn: cn=default,ou=policies,dc=example,dc=com
cn: default
objectclass: top
objectclass: device
objectclass: pwdPolicy
objectclass: pwdPolicyChecker
pwdallowuserchange: TRUE
pwdattribute: userPassword
pwdcheckmodule: mmc-check-password.so
pwdcheckquality: 0
pwdexpirewarning: 600
pwdfailurecountinterval: 0
pwdgraceauthnlimit: 5
pwdinhistory: 5
pwdlockout: TRUE
pwdlockoutduration: 0
pwdmaxage: 7776000
pwdmaxfailure: 5
pwdminlength: 8
pwdmustchange: TRUE
pwdsafemodify: FALSE
And my user:
dn: cn=Jacques Foucry,ou=People,dc=example,dc=com
c: France
cn: Jacques Foucry
gidnumber: 1000
givenname: Jacques
homedirectory: /home/jfoucry
loginshell: /bin/zsh
mail: jacques.foucry(a)example.com
objectclass: inetOrgPerson
objectclass: mozillaAbPersonAlpha
objectclass: sambaSamAccount
objectclass: posixAccount
objectclass: top
objectclass: shadowAccount
objectclass: pwdPolicy
ou: RT_Users
postalcode: 75009
pwdattribute: userPassword
sambaacctflags: [U]
shadowlastchange: 15987
shadowmax: 120
shadowmin: 7
shadowwarning: 7
sn: Foucry
uid: jfoucry
uidnumber: 1010
userpassword: --password--
On the replica mv. I created a slapd.conf file (I cannot understand the
"new" syntax).
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/mozillaAbPersonAlpha.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/pureftpd.schema
include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
loglevel config sync
modulepath /usr/lib/ldap
moduleload back_hdb
database hdb
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw {SSHA}--password--
directory /var/lib/ldap
referral ldaps://192.168.72.13
syncrepl rid=020
provider=ldaps://192.168.72.13
type=refreshOnly
interval=00:08:00:00
retry="60 10 300 +"
filter="(objectClass=*)"
scope=sub
attrs="*"
bindmethod=simple
schemachecking=off
searchbase="dc=exmaple,dc=com"
binddn="cn=syncuser,dc=exmaple,dc=com"
credentials=--password--
tls_reqcert=never
When I start slapd on the slave vm, It sound correct but only few off my
user records are sync. For example mine is not.
One the master:
# ldapsearch -x -b"ou=people,dc=example,dc=com" uid=jfoucry
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: uid=jfoucry
# requesting: ALL
#
# Jacques Foucry, People, example.com
dn: cn=Jacques Foucry,ou=People,dc=example,dc=com
c: France
cn: Jacques Foucry
mail: jacques.foucry(a)example.com
gidNumber: 1000
givenName: Jacques
homeDirectory: /home/jfoucry
loginShell: /bin/zsh
ou: RT_Users
postalCode: 75009
shadowMax: 120
shadowMin: 7
shadowWarning: 7
sn: Foucry
uidNumber: 1010
uid: jfoucry
objectClass: inetOrgPerson
objectClass: mozillaAbPersonAlpha
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: pwdPolicy
pwdAttribute: userPassword
shadowLastChange: 15987
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
On the slave:
ldapsearch -x -b"ou=people,dc=exmaple,dc=com" uid=jfoucry
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: uid=jfoucry
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
I can't figure what's wrong. Why some records are sync and other are
not? Is it because of ppolicy?
Thanks in advance for your help,
Jacques Foucry
--
Jacques Foucry
*NOVΛSPARKS *
IT Manager
Tel : +33 (0)1 42 68 12 61
jacques.foucry(a)novasparks.com
9 years, 11 months
remove unused schema from cn=config in n-way multi-master setup
by Igor Zinovik
Hello, opeldap-technical@ readers.
I have a 3 nodes n-way multi-master setup configured accroding to OpenLDAP
Admin Guide.
Currently my catalog configuration stores custom schema which I made some
time ago, but
it no longer needed, so I would like to delete my custom schema from
configuration.
Replication is bothering me the most. I understand that consequences would
be unexpectable
when one of my server will see that other node is telling him to delete
cn={14}example,cn=schema,cn=config.
So my main question is how to correctly disable replication in n-way
multi-master setup?
Objects that are stored in catalog do not use attributes or object classes
that are defined in
custom schema.
In my setup write operations are directed only to single node of a cluster.
I would like to ask for advice about my deletion plan.
0. Make backup of current cn=config and data
1. Disable replication via deletion olcServerID in cn=config and setting
olcMirrorMode to FALSE
2. Direct write operations to third node
3. Stop slapd instance on first node
4. Edit configuration (remove custom schema from file, renumber siblings in
cn=schema,cn=config)
5. Load new configuration into /etc/openldap/slapd.d
6. Start slapd instance on first node
7. Check that schema is absent in cn=config on first node
8. Repeat steps from 3-7 on second node
9. Direct write operations to first node
10. Repeat steps from 3-7 on third node
11. Turn on replication in cluster
If it matters i use OpenLDAP 2.4.33 (x86_64).
9 years, 11 months
Multiple CSN use
by Emmanuel BILLOT
Hi,
I read a thread about multiple CSN.
If a server have to replicate multiple parts from several servers, it must
have multiplace CSN.
Now we use multiple database for having multiple CSN (one subordinate per
remote server), but this thread seems to talk about multiple CSN using with
one database.
What should be a simple conf example to use multiple CSN values ?
I didn't find any doc about using multiple CSN with "correctly used SIDs".
http://www.openldap.org/lists/openldap-technical/201011/msg00153.html
"But the SIDs will only be used correctly if the URLs in the ServerID
directive match the actual URLs given to the slapd -h option."
Regards,
9 years, 11 months
contextCSN format
by Emmanuel BILLOT
Hi,
When using refreshonly replication, i cannot see any rid or sid info on the
consumer contextCSN
Oct 13 21:39:24 seshat-test slapd[5053]: do_syncrep2:
cookie=rid=003,sid=003,csn=20131013024923.410481Z#000000#000#000000
Oct 13 21:39:24 seshat-test slapd[5053]: slap_queue_csn: queing 0x8765080
20131013024923.410481Z#000000#000#000000
Oct 13 21:39:24 seshat-test slapd[5053]: slap_graduate_commit_csn: removing
0x8761170 20131013024923.410481Z#000000#000#000000
Whereas ServerID is set on provider.
What could explain this ?
9 years, 11 months
memberof overlay results in unexpected slapd death?
by Paul B. Henson
Our LDAP infrastructure is currently running 2.4.35, and consists of two
read/write masters configured in mirror mode behind the load balancer, with
three additional read-only slaves using syncrepl. We recently decided to add
the memberof overlay to our configuration, due to an application that did
not support querying the groups for members.
I updated our configuration to load the module, and add the overlay, and
proceeded to rip through all of our groups removing and then re-adding the
members in order to populate the memberOf attribute on the user objects.
While doing so, there were errors logged on all of the servers:
Oct 10 04:26:09 fosse slapd[9944]: conn=75373 op=184748:
memberof_value_modify DN="uid=tdnguyen1,ou=user,dc=cs
upomona,dc=edu" delete memberOf="uid=classes,ou=group,dc=csupomona,dc=edu"
failed err=16
This was expected, as the memberOf attribute did not exist in our current
directory. However, what was unexpected was that the slapd processes started
to mysteriously die while I was trying to repopulate the groups. No log
messages, or any other indication of the failure, just attribute delete
errors:
Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify
DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete
memberOf="uid=mhr31806,ou=group,dc=csupomona,dc=edu" failed err=16
Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify
DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete
memberOf="uid=mhr_classes,ou=group,dc=csupomona,dc=edu" failed err=16
Then the process was gone. It was definitely related to mass group updates,
they would run for hours with no problems under general use, but as soon as
I started churning group members, bam, one or two of them would go away.
I ended up backing out the modification, dumping the database, removing all
of the memberOf attributes, and reloading it. I will try to duplicate this
in a test environment with debugging enabled and see if I can get a better
idea what's going on, but I was just curious if anyone had seen anything
like this or knew of any underlying issues with the memberof overlay.
Thanks much.
9 years, 11 months
mysterious glue record with empty dn
by Paul B. Henson
While I was trying to recover my directory from an aborted attempt to
implement the memberof overlay, I ended up dumping the database with slapcat
and then reloading it with slapadd after removing the now invalid MEMBEROF
attributes that lingered after the overlay was disabled.
Strangely, on some of my servers, a glue object with an empty DN showed up
in the slapcat output:
dn:
objectClass: glue
structuralObjectClass: glue
entryUUID: 411f0301-e857-4228-a22d-c5d1451d4496
creatorsName: cn=ldaproot,dc=csupomona,dc=edu
createTimestamp: 20131007210011Z
entryCSN: 20131007210011.273579Z#000000#000#000000
modifyTimestamp: 20131007210011Z
modifiersName: cn=idmgmt,ou=user,ou=service,dc=csupomona,dc=edu
slapadd refused to load the input file with this record at the top, I ended
up deleting it and then it seemed to load fine. I'm not sure where this
record came from? From what I could research, it seems glue records are
created when you delete part of the hierarchy that is in between the top and
some lower record? I don't think I did that, plus I don't see why it would
have an empty DN? This must have something to do with my attempt to
implement the memberof overlay, as I have never seen it before.
Any thoughts?
Thanks.
9 years, 11 months
memberof overlay replicating memberOf attribute?
by Paul B. Henson
Based on the documentation, my understanding was that the memberof overlay
maintained the memberOf attribute locally, and this attribute was not
replicated? While I was recently working on implementing the memberof
overlay, I noticed that after I had enabled it on one server, before
enabling it on another, the memberOf attribute seemed to be replicated from
the server on which the overlay was enabled to the one on which it was not:
Oct 7 18:30:18 filmore slapd[28994]: UNKNOWN attributeDescription
"MEMBEROF" inserted.
Oct 7 18:30:18 fosse slapd[3047]: UNKNOWN attributeDescription "MEMBEROF"
inserted.
Oct 10 16:23:08 pip-dev slapd[7030]: slapd starting
Oct 10 16:23:08 pip-dev slapd[7030]: UNKNOWN attributeDescription "MEMBEROF"
inserted.
This seems contrary to the documentation and I found it confusing. Am I
missing something?
Thanks.
9 years, 11 months
unixUserPassword and userPassword
by jupiter
Hi,
I am migrating user account entries from an old openldap AD to
openldap BDB. Both LDAP client authentications are implemented in
Linux, the former in CentOS 5, and the latter in CentOS 6.
But the major problem is that the old openldap AD uses encrypted
password in "unixUserPassword:" while the openldap BDB uses base64
"userPassword::".
The option for solution I could think of are:
(a) Convert the encrypted password from unixUserPassword format to
userPasswor, then I can use ldapmodify to change userPassword. Is it
possible? If it is, appreciate more details.
(b) Change LDAP client authentication to use unixUserPassword. I
haven't found any document to configure Linux client authentication to
use unixUserPassword.
In fact, I could not find any document regarding details of uing
unixUserPassword. Any suggestions, tips and advice are very much
appreciated.
Thank you.
Kind regards,
jupiter
Sorry for asking a non-dev question, but I could not find any solution
from openldap document, nor from Internet searching.
Thank you and appreciate any advice.
Kind regards,
jupiter
9 years, 11 months
