unable to change userPassword
by Adam Williams
I have a user:
[root@gomer ~]# ldapsearch -D
'cn=Manager,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us' -b
"uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us" -w
xxxxxxxxx -x
# extended LDIF
#
# LDAPv3
# base <uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us>
with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# testuser, People, gomer.mdah.state.ms.us
dn: uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us
uid: testuser
cn: test user
telephoneNumber: 5766888
roomNumber: IS
homePhone: 3738042
givenName: test
sn: user
mail: testuser@dc=mdah,dc=state,dc=ms,dc=us
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: sambaSamAccount
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 101
homeDirectory: /home/testuser
gecos: test user,IS,5766888,3738042
sambaSID: S-1-5-21-2139886109-2393431639-217723040-2002
sambaPasswordHistory:
00000000000000000000000000000000000000000000000000000000
00000000
sambaLMPassword: xxxxxxxxxxxxxxxxxxxxxxx
sambaNTPassword: xxxxxxxxxxxxxxxxxxxxxxx
sambaPwdMustChange: 1196173997
sambaPwdLastSet: 1196174310
sambaAcctFlags: [U ]
shadowLastChange: 13844
shadowMax: 99999
userPassword:: e0NSWVBUfWNyTxxxxxxxxxxxxxxx=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
and an ldif file:
[root@gomer ~]# cat testuserchangepassword.ldif
dn: uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us
changetype: modify
userPassword: {CRYPT}crLJzfHxxxxxxxx
and I runt he command to change it, but then the password isn't changed
when you do the same ldapsearch:
[root@gomer ~]# ldapmodify -D
"cn=Manager,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us" -w xxxxxxxxx -x -v -f
testuserchangepassword.ldif
ldap_initialize( <DEFAULT> )
replace userPassword:
{CRYPT}crLJzfHxxxxxxxx
modifying entry
"uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us"
modify complete
[root@gomer ~]# ldapsearch -D
'cn=Manager,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us' -b
"uid=testuser,ou=People,dc=gomer,dc=mdah,dc=state,dc=ms,dc=us" -w
xxxxxxxxx -x|grep userPassword
userPassword:: e0NSWVBUfWNyTxxxxxxxxxxx=
any idea why it says the modify is successful but its not changing the
userPassword?
15 years, 10 months
delta-syncrepl replica out of date
by Francis Swasey
I have a master and nine delta-syncrepl replicas all running on RHEL 4
using OpenLDAP 2.3.38 on the master and all replicas.
The master is configured to purge entries from the accesslog after 12
hours (and checks every 2 hours). I forget where I grabbed that from
why I used it.
Anyway, I have discovered that if one of the replicas gets more than 12
hours behind (ie, is shutdown or we reload the database from yesterday),
that it will grab all the updates that have happened in the last 12
hours and then the CSN of the replica and the master will be in
agreement, but the changes that happened more than the 12 hours (of the
accesslog) ago are not present on the replica.
Is this a configuration mistake I have made (other than setting the
accesslog purge time to 12 hours) or is this a limitation (that I likely
knew at one time and then forgot and now have relearned the hard way)?
Is there an option I can set on the replica's so they will refuse to
start if their CSN is older than the oldest record in the accesslog of
the master when they start up?
If this has been discussed in the past, I'm sorry, I did search, but not
certain of the terms to use, I didn't have any luck finding anything
that looked promising.
Here's the relevant parts of the master's slapd.conf
database hdb
suffix cn=accesslog
directory /var/lib/ldap/accesslog
rootdn cn=accesslog
checkpoint 1024 5
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
database bdb
suffix dc=example,dc=com
...
overlay syncprov
syncprov-checkpoint 1000 60
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 12:00 02:00
And from the replica's:
database bdb
suffix dc=example,dc=com
...
syncrepl rid=100
provider=ldaps://ldaprw.example.com
bindmethod=simple
binddn="cn=MySyncUser,dc=example,dc=com"
credentials=NotMyRealPassword
searchbase="dc=example,dc=com"
logbase="cn=accesslog"
logfilter="(&(objectclass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry=30,+
syncdata=accesslog
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
15 years, 10 months
Re: syncrepl LDIF kickstart file
by Gavin Henry
<quote who="Scott Classen">
> On Nov 21, 2007, at 2:53 PM, Gavin Henry wrote:
>
>>> I've been thinking about this some and I am still confused about what
>>> is probably a fairly simple syncrepl concept.
>>>
>>> What I have been trying to do is synchronize the cn=config base from
>>> the PROVIDER to the CONSUMER. My hope was that by replicating
>>> cn=config then all the other databases (well, really only the primary
>>> BDB for now) would then be automagically synched too. Does this make
>>> sense?
>>
>> Rather than try to debug all of above, I'm stepping back and trying to
>> understand what you are doing.
>>
>> So you are trying to sync the providers config to the consumer?
>>
>> This is like MirrorMode or Multi-Master.
>>
>> If you have a master and a slave (the slave with a syncprov overlay
>> on),
>> then plan to bootstrap from the slave for another slave, then that
>> makes
>> sense, i.e. what you plan above is ok.
>>
>> Can you clarify?
>
> OK. The BIG picture. I am running a small operation here. I will
> probably never have more than 100 users in my LDAP directory.
> I have one machine that is currently running openldap 2.4.6 as my one
> and only (i.e. Master) LDAP server.
> Now that LDAP is up and running I am starting to slowly migrate
> existing users over to the LDAP directory.
> It is absolutely imperative that if the master server becomes
> unavailable that users can still function.
> Therefore, I was trying to set up a backup LDAP server. My research
> has led me to the conclusion that I should be using syncrepl (of the
> regular sort ... not mirrormode or multi-master) to create my second
> backup LDAP server.
Ok.
>
> I thought by installing openldap 2.4.6 on a second machine and using a
> short 10-15 line seed.ldif file it would talk to the master LDAP
> server, get the cn=config from the master and see that in addition to
> the cn=config base there is also another BDB base
> (dc=example,dc=als,dc=lbl,dc=gov), and then it would sync up that guy
> too.
>
But if you replicate the config, you are creating another master. You have
to create a seperate config for the slave. There is no harm from then on
to create a seed.ldif and replicate your cn=config from another slave.
Gavin.
15 years, 10 months
Re: syncrepl LDIF kickstart file
by Gavin Henry
<quote who="Scott Classen">
>>> I thought by installing openldap 2.4.6 on a second machine and
>>> using a
>>> short 10-15 line seed.ldif file it would talk to the master LDAP
>>> server, get the cn=config from the master and see that in addition to
>>> the cn=config base there is also another BDB base
>>> (dc=example,dc=als,dc=lbl,dc=gov), and then it would sync up that guy
>>> too.
>>>
>>
>> But if you replicate the config, you are creating another master.
>> You have
>> to create a seperate config for the slave. There is no harm from
>> then on
>> to create a seed.ldif and replicate your cn=config from another slave.
>>
>> Gavin.
>
> Yes, I see your point. This was a concern of mine. I was suspicious
> that simply replicating the cn=config from the master would not work
> as a seed for a slave I was envisioning.
>
> So I need a slave-specific cn=config?
Or just one master to replicate from.
>
> Is it possible to store a second cn=config on the master server that
> is specific for slave machines?
> How would you do this? What would it look like?
Hmmm..., you could do (not tried this):
slapcat -n 0
Do this on a configured slave to get the right config.ldif etc.
change all DNs to whatever you plan to store the data under, and then use
the rwm overlay to deliver it all out of the directory in the original
cn=config format.
You could then replicate from that.
Just a thought.
>
> Could I make a cn=slave,cn=config and use that as the cn=config for
> all slave machines.
>
> Thanks,
> Scott
>
15 years, 10 months
Re: syncrepl LDIF kickstart file
by Gavin Henry
> I've been thinking about this some and I am still confused about what
> is probably a fairly simple syncrepl concept.
>
> What I have been trying to do is synchronize the cn=config base from
> the PROVIDER to the CONSUMER. My hope was that by replicating
> cn=config then all the other databases (well, really only the primary
> BDB for now) would then be automagically synched too. Does this make
> sense?
Rather than try to debug all of above, I'm stepping back and trying to
understand what you are doing.
So you are trying to sync the providers config to the consumer?
This is like MirrorMode or Multi-Master.
If you have a master and a slave (the slave with a syncprov overlay on),
then plan to bootstrap from the slave for another slave, then that makes
sense, i.e. what you plan above is ok.
Can you clarify?
> My concern is that I am using TLS and currently the names of
> the crt and key files are different for the PROVIDER and CONSUMER so
> simply replicating the cn=config may not actually work unless I remain
> consistent in my naming of the SSL files. I guess I can do this, but I
> thought to clarify the idea with the openldap experts first.
>
> I'm still hopeful. I really like the idea of building a new machine,
> compiling openldap, slapadding a seed LDIF file and instantly having a
> backup slave LDAP server.
>
> Thanks,
> Scott
>
>
15 years, 10 months
Question on bind using Kerberos Service Ticket.
by Austin Cherian
Hi,
Im quite new to Openldap and am searching for answers to some
questions on a particular case i have, i'd be glad if some one could
help me out on this particular topic.
I have a situation where i have to perform an LDAP bind to a given
LDAP server with only being provided a service ticket to that
particular LDAP server and nothing else, i have already explored the
possibility of using SASL authentication method with GSSAPI as the
mechanism, however i guess the GSSAPI mechanism takes user credentials
as input and moves through the Kerberos protocol to finally provide
the LDAP server with the service ticket.
Im looking for a method where i can just provide the service ticket (
which i acquired form another host, where the client entered the
credentials and Kerberos returned with a service ticket ) to the LDAP
server and hope to achive the LDAP bind.
is there any ldap_bind method that just takes the service ticket as
input and allows a bind to take place, or is it possible to use a SASL
mechanism to make this happen, any suggestions will be appreceiated at
this time.
Regards,
Austin.
15 years, 10 months
strict ldif check
by 1
Hi everyone!
This may be a simple question but googling didn't help me at all.
Let's consider ldap add operation. According to RFC4511
Fields of the Add Request are:
- entry: the name of the entry to be added. The server SHALL NOT
dereference any aliases in locating the entry to be added.
- attributes: the list of attributes that, along with those from the
RDN, make up the content of the entry being added. Clients MAY or
MAY NOT include the RDN attribute(s) in this list. Clients MUST
NOT supply NO-USER-MODIFICATION attributes such as the
createTimestamp or creatorsName attributes, since the server
maintains these automatically.so adding something like
dn: uid=test,dc=edu,dc=ru
objectClass: testClass
while testClass classify uid as MAY attribute
is correct. Ain't I wrong? Though if you try to do it via OpenLDAP you get
"Naming violation. Naming attribute uid is not present in entry."
Doesn OpenLDAP really violates RFC here? Or I just don't get something?
Thanks in advance!
Regards,
Alexander
15 years, 10 months
Filter - greater or equal - ORDERING
by Andreas Schoe
Hello,
I want to use following filter: "uid>=branch" (greater or equal).
Log entry: filter="(?=undefined)".
I searched the web and found out that I have to add an ORDERING rule to the
attribute type definition of 'uid'.
Is that right?
Where can I add this rule, in core.schema the type definition of 'uid' is a
comment. I uncomment it but slapd says the attribute is declared twice. I
can´t find any other entries. In cosine.schema the entry is a comment too.
Where did I found the definition?
(openldap 2.3.38)
Andreas
15 years, 10 months
Syncrepl, dumb question
by gianni mazzini
I am newbie, I am trying to configure Syncrepl beetwen 2 OpenLDAP servers.
I have read FAQ, Admin's guide, mailing lists, but I didn't find any answer about my problem.
The master server is on 192.168.1.255 subnet and is working fine.
Now I am triyng to replicate it to another server in 192.168.123.255 subnet.
Replication from provider to consumer works good (if I write an entry in provider, it will be replicated to consumer), but if I try to write to consumer (ldapadd -x -D cn=Manager,dc=DOMAIN -W -f file.ldif) I get only this answer:
adding new entry "cn=newentry,dc=DOMAIN"
ldap_add: Referral (10)
referrals:
ldap://192.168.1.100/cn=newentry,dc=DOMAIN
but nothing appears in provider's log and LDAP databases.
How can configure Syncrepl in order to write to consumer and replicate entries to provider too?
(OpenLDAP: slapd 2.3.30 on Debian Etch).
Following examples in FAQ, I configured provider and consumer as showed below:
=================CONSUMER=================
[cut]
suffix "dc=DOMAIN"
rootdn "cn=Manager,dc=DOMAIN"
rootpw {SSHA}something-hashed
[cut]
access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword
by dn="cn=syncuser,dc=DOMAIN" write
by anonymous auth
by self write
by * none
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=syncuser,dc=DOMAIN" write
by * read
syncrepl rid=1
provider=ldap://192.168.1.100:389
type=refreshAndPersist
retry="60 +"
searchbase="dc=DOMAIN"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncuser,dc=DOMAIN"
credentials=secret
updateref ldap://192.168.1.100
=================PROVIDER=================
[cut]
suffix "dc=DOMAIN"
rootdn "cn=Manager,dc=DOMAIN"
rootpw {SSHA}something-hashed
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
[cut]
access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword
by dn="cn=admin,dc=ENIGMA" write
by dn="cn=syncuser,dc=ENIGMA" write
by anonymous auth
by self write
by * none
access to *
by dn="cn=admin,dc=ENIGMA" write
by dn="cn=syncuser,dc=ENIGMA" write
by * read
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
15 years, 10 months
