(ITS#6544) how to implement password policy
by dsbrar16＠yahoo.com
Full_Name: Devender Singh
Version: openldap 2.4.16
OS: RHEL5.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (122.177.190.226)
Hello Dear,
Please let me know, how to implement ppolicy in openldap2.4.16. I
am using RHEL5.4
I have followed below steps on installation time:
**************************************************
Installing BerkeleyDB
**************************************************
1) Create build_unix directory in /opt directory
2) Copy db-4.7.25.tar.gz to /opt/build_unix directory
3) Goto /opt/build_unix directory
4) gzip -d db-4.7.25.tar.gz
5) tar xvf db-4.7.25.tar
6) db-4.7.25/dist/configure
7) make
8) make install
9) vi /root/.bash_profile
10) Add below lines in .bash_profile of root user
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib
export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib
11) Close existing PUTTY and start new PUTTY
**************************************************
Before Installation check the below packages:
#rpm qa|grep openssl*
After the above command if you dont find the all openssl packages than install
them via yum command
**************************************************
Installing OpenLDAP
**************************************************
1) Copy openldap-stable-20090411.tgz to /opt directory
2) gunzip -c openldap-stable-20090411.tgz | tar xf -
3) cd openldap-2.4.16
4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include
-I/usr/local/ssl/include/openssl"
5) export CPPFLAGS
6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib
-L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib
-R/usr/local/ssl/lib"
7) export LDFLAGS
8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib"
9) export LD_LIBRARY_PATH
10) ./configure
11) make depend
12) make
13) make install
14) vi /root/.bash_profile
15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export
PATH=$PATH:$HOME/bin:/usr/local/sbin)
16) Close existing PUTTY and start new PUTTY
**************************************************
Thanks in Advance.
Regards,
Devender Singh
(+919818107222)
12 years, 10 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
Ryan Steele wrote:
> Actually, it would appear I'm hitting the same problem as the OP in this thread:
>
> http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require
> authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results
>
>
> I say that because when I get prompted for authentication by the slave (instead of having the referral handled
> server-side), I see this corresponding entry in the master's logs:
>
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389)
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text=
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND
> May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed
>
>
> So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down...
>
The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the
directory), so it's not just third party utilities. It really does appear as though the chain overlay is stripping the
DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the
master and fails because there is no DN before a referral is presented to the client that initially sent the update to
the slave. I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't
being denied by ACL's or anything like that.
I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ
(http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not
think that they are required or causing this problem. In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the
slaves (as the FAQ says) just to be absolutely sure, but it made no difference.
I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just
prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that
you made, Pierangelo. In either case, the behavior is broken. Exactly where, I'm still trying to figure out, but would
definitely appreciate any input from more seasoned OpenLDAP developers.
12 years, 10 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
Actually, it would appear I'm hitting the same problem as the OP in this thread:
http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require
authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results
I say that because when I get prompted for authentication by the slave (instead of having the referral handled
server-side), I see this corresponding entry in the master's logs:
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389)
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text=
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND
May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed
So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down...
12 years, 10 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
After patching, and using the same configuration as I had when the chain overlay was causing issues with slapcat and
restarting slapd, I now get prompted with a referral instead of it being automatically chased. However, it does
automatically fill in the DN and password to rebind with:
root@somehost:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover
159 entries read
add: 0, rename: 0, modify: 1, delete: 0
Action? [yYqQvVebB*rsf+?] y
Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com.
You are not logged in to ldap://ldapmaster.example.com:389 yet.
Type '!' or 'y' to do so.
Rebind? [y!nB*qQ?] y
--- Login
Type M-h for help on key bindings.
Filter or DN: cn=admin,dc=example,dc=com
Password: ***********
Bound as cn=admin,dc=example,dc=com.
Done.
Before, I never got prompted with this message when using ldapvi, which makes me think that chaining is no longer
working. For reference, I am using the same configuration as is documented in test022-ppolicy:
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}back_ldap.la
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: ldap://ldapmaster.example.com
olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self
I am still looking in to what might be causing this to fail.
12 years, 10 months
(ITS#6247)
by daniel＠pluta.biz
I've enabled <g-differential> format as default for the Root-DSE's
serverTime attribute (and thus removed the #ifdef
CTM_G_DIFFERENTIAL_SERVERTIME).
The updated patch can be downloaded from here:
ftp://ftp.openldap.org/incoming/daniel-pluta-100503.patch
Please use -DCTM during compilation.
Below is a sample schema file called "example.schema" and some sample
data called "example.ldif". In addition also some sample ldif change
files and filter statements are provided to:
- offer you some first, quick and easy testing possibilities regarding
"LDAP server side current time matching"'s matching rules in action
- and to give us a chance to get more detailed feedback regarding
problems concerning the LDAP specification in common (e.g.
violation of the standard) and slapd in detail.
Many thanks!
Depending on your feedback and the current status of the discussion on
ldapext the code will be updated accordingly.
It's currently just a prototype, the obviously open implementation TODOs
are:
- use operation's time-stamp instead of system calls (OpenLDAP 2.5?)
- X.680 duration-syntax (instead of custom offset fun: "n#n#n#n#n#n")
- further cleanups: function aggregation / coding style / ...
- integration into "make test"?
e.g. using FTPL: http://www.code-wizards.com/projects/libfaketime (?!)
#=========================================
$: cat example.schema
attributetype ( 1.3.6.1.4.1.7650.666.1.1.1
NAME 'demoTs1'
DESC 'draft-pluta-ldap-srv-side-current-time-match: 1st demo attribute'
EQUALITY nowMatch
ORDERING nowOrderingMatch
SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.0
)
attributetype ( 1.3.6.1.4.1.7650.666.1.1.2
NAME 'demoTs2'
DESC 'draft-pluta-ldap-srv-side-current-time-match: 2nd demo attribute'
EQUALITY nowMatch
ORDERING nowOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
)
attributetype ( 1.3.6.1.4.1.7650.666.1.1.3
NAME 'demoTs3'
DESC 'draft-pluta-ldap-srv-side-current-time-match: 3rd demo attribute
(violat
es RFC4517)'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
)
objectclass ( 1.3.6.1.4.1.7650.666.1.2.1
NAME 'ctmDemo'
DESC 'draft-pluta-ldap-srv-side-current-time-match: demo objectClass'
AUXILIARY
MAY ( demoTs1 $ demoTs2 $ demoTs3 )
)
#==DATA=======================================
$: cat example.ldif
dn: dc=example,dc=com
objectClass: domain
objectClass: extensibleObject
objectClass: top
dn: ou=dev,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
objectClass: ctmDemo
ou: dev
demoTs1: 20100101000000Z
demoTs2: 20100101000000Z
demoTs3: 20100101000000Z
#==LDIF=CHANGE=FILES==========================
$: cat add_delete.ldif
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs1
demoTs1: 20100101000000Z
-
add: demoTs1
demoTs1: 20100201000001Z
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs2
demoTs2: 20100101000000Z
-
add: demoTs2
demoTs2: 20100201000001Z
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs3
demoTs3: 20100101000000Z
-
add: demoTs3
demoTs3: 20100201000001Z
#-----------------------------------------
$: cat add_mv.ldif
dn: ou=dev,dc=example,dc=com
changetype: modify
add: demoTs1
demoTs1: 20110201000000Z
-
add: demoTs1
demoTs1: 20120201000000Z
-
add: demoTs1
demoTs1: 20130201000000Z
-
add: demoTs1
demoTs1: 20100201000000Z
dn: ou=dev,dc=example,dc=com
changetype: modify
add: demoTs2
demoTs2: 20110201000000Z
-
add: demoTs2
demoTs2: 20120201000000Z
-
add: demoTs2
demoTs2: 20130201000000Z
-
add: demoTs2
demoTs2: 20100201000000Z
dn: ou=dev,dc=example,dc=com
changetype: modify
add: demoTs3
demoTs3: 20110201000000Z
-
add: demoTs3
demoTs3: 20120201000000Z
-
add: demoTs3
demoTs3: 20130201000000Z
-
add: demoTs3
demoTs3: 20100201000000Z
#-----------------------------------------
$: cat reset.ldif
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs1
-
add: demoTs1
demoTs1: 20100101000000Z
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs2
-
add: demoTs2
demoTs2: 20100101000000Z
dn: ou=dev,dc=example,dc=com
changetype: modify
delete: demoTs3
-
add: demoTs3
demoTs3: 20100101000000Z
#==FILTER=STATEMENTS======================
#BTW: You can use the FakeTime Preload Library
#(link above) to easily fake slapd's time to
#get constant results for automatic testing
(demoTs1=20100101000000Z)
(demoTs1<=NOW)
(demoTs1>=NOW)
(demoTs1>=-2#0#0#0#0#0)
(demoTs2=20100101000000Z)
(demoTs2<=NOW)
(demoTs2>=NOW)
(demoTs2<=0#-1#0#0#0#0)
(demoTs3=20100101000000Z)
#Only possible if compiled using:
#-DRFC4517_ASSERTION_SYNTAX_VIOLATION
(demoTs3<=NOW)
(demoTs3>=NOW)
12 years, 10 months
Re: (ITS#6543) make test failure
by quanah＠zimbra.com
--On Monday, May 03, 2010 3:50 PM +0000 sven.falempin(a)gmail.com wrote:
> No race errors found after 10 iterations
> Found 2 errors
>>>>>>> Exiting with a false success status for now
>>>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb.
The point of these lines about exiting with false success is that you are
to ignore the issue. I.e., please don't file a bug report about failure
with test058. That's why it exits with "success".
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
12 years, 10 months
(ITS#6543) make test failure
by sven.falempin＠gmail.com
Full_Name: Sven
Version: 2.4.21
OS: OpenBSD
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.80.162.131)
Using OpenBSD 4.3 or OpenBSD 4.7
with both bdb 4.6.21 and 5.0.21
The following test failed , to help reproduction i do a trick explained below:
>>>>> Starting test058-syncrepl-asymmetric for hdb...
running defines.sh
Initializing master configurations...
Initializing search configurations...
Starting central master slapd on TCP/IP port 9011...
[...] lots of output [...]
Using ldapdelete to delete entry on site1 master...
Starting central master again...
Using ldapsearch to check that entry was deleted on central master...
Using ldapsearch to check that entry was deleted on central search...
No race errors found after 10 iterations
Found 2 errors
>>>>>> Exiting with a false success status for now
>>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb.
To trigger the failure i do an ugly #find / | grep whatever
12 years, 10 months
Re: (ITS#6247)
by Kurt＠OpenLDAP.org
In regards to my X.501 comments, see "Matching Rule Requirements" =
section of X.501(93). Note that only the 93 edition is normative here.
I note that you actually need to specify the syntaxes and matching rules =
in X.500 terms, and then simply specify a string representation for the =
syntaxes for use in LDAP. See RFC 4521, Section 5.1 (for LDAP Syntaxes) =
and 5.2 (for Matching Rules) and Section 5 more generally for schema.
As far as your I-D goes, I currently deferring to Steve's initial review =
at this early stage in its development because I'm busy and I trust =
Steve to tease out any obvious ASN.1, X.500, and/or LDAP issues with =
your I-D and to "educate" you as might be necessary. I'll join in =
later, possibly after you revise your I-D once or twice to address =
Steve's comments.
-- Kurt=
12 years, 10 months
Re: (ITS#6247)
by daniel＠pluta.biz
Kurt Zeilenga schrieb:
> On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote:
>
>> The patch can be downloaded here:
>> ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch
>>
>> Changes:
>> - removed extensible matching rules strictly associated with
>> dedicated syntaxes
>> - added two universal matching rules instead:
>> - nowMach (equality matching rule)
>> - nowOrdering (ordering matching rule)
>> - these two rules also support extensible match filters
>
> Your comments imply these rules could be used as attribute type
> equality and ordering rules.
In general my intention is neither to violate X.501 nor changing the
ASN.1 Generalized Time syntax.
Instead the introduction of a compatible/similar/derived attribute value
syntax (e.g. generalizedTime') which supports matching against
client-side known time-stamps *and* server-relative time-stamps (like
NOW or NOW-1Y3M... or X.680 period formats) seems to be fine for me.
In the following generalizedTime' is such a kind of a (very) similar
syntax to the well-defined generalizedTime.
Regarding the EQ/ORD matching rule applicability:
The attribute type is generalizedTime' and the assertion value is for
example NOW which server-internally implicitly also represents a (at
least some kind of possibly not ITU specified?) generalizedTime' conform
assertion value:
NOW is the at client side unknown current time of the server in
generalizedTime'. What's your suggestion regarding a possible solution
on how to support EQ and ORD matching of attribute values compared to
the server side current time?
> I don't believe the met the
> requirements (see X.501) to be used in that manner. That is, they
> only make sense as extensible matching rules.
I really would like to try to understand your concerns. Could you please
give me some links to chapters/sections in X.501 where I can find more
details. Note: I've currently only access to the standard of the year 2006.
The class is generalizedTime' and during EQ/ORD matching two instances
of generalizedTime' are compared:
1. Attribute value of an entry (generalizedTime')
2. Assertion value aka expanded-NOW (generalizedTime')
>> To publish a correct server current time time-stamp value within Root-DSE:
>> - apply the bugfix from ITS#6541
>> - and use -DCTM_G_DIFFERENTIAL_SERVERTIME
>
> #ifdef's should, IMO, be generally avoided.
it will be removed as soon as the above mentioned bug is fixed in HEAD
>> To extend generalizedTime attribute types to also support "NOW" as
>> assertion value:
>> - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION
>
> The generalized time syntax is not ours to alter. Introduction of
> such a change would, it seem, lead to interoperability problems.
In my opinion the chosen name for the #ifdef is more than obvious.
Additionally the related comment in the patch's source already say's
that this "extension" is more a violation than an extension.
That's why the #ifdef currently is and probably stays in action (or will
be removed) in the future. As a side-effect this #ifdef could possibly
invoke some disussions... ;-)
It's probably worth to discuss this (violation) in more detail to
provide a solution in regard to a broader applicability of this matching
feature in LDAP. Broader/easier usage/readbility is also the background
I've decided to skip the extensible matching rules and introduce EQ and
ORD instead.
E.g. Clients that are connecting to a server that announces the
supportedFeature "current time matching" could make notice of that and
also support "NOW" as assertion value for createTimestamp and so on...
(I've not very well thought about that in detail, yet).
You are right, it's just a work in progress and you are very welcome to
join the discussion on ldapext.
12 years, 10 months
Re: (ITS#6542) Segmentation Fault if config file (ldif) got changed
by hyc＠symas.com
felix.schuster(a)gmx.at wrote:
> Full_Name: Felix
> Version: 2.4.19
> OS: Linux/Gentoo
> URL:
> Submission from: (NULL) (78.142.131.97)
>
>
> Using the new configuration scheme, I changed
> /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap
> instance. When I tried to restart openldap it gaves me a Segmentation Fault
> error. Even if I called the changes off, openldap refused to start (furthermore
> segfaulted). I needed to get a copy of the original configuration file from my
> backup to successfully start openldap again.
> I think it's somewhere ok to deny working with a hand-changed configuration, but
> I think we will need a friendly advise, no unfriendly Segementation Fault error.
>
cn=config is an LDAP database. Like any other LDAP database, you are only
supposed to use ldapadd/modify/delete to write to it while slapd is running.
You would probably get segfaults if you hand-edited the data files in a
back-bdb database too. And no, we will not add code to protect from such misuse.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
