RE: ppolicy and Red Hat Linux
by Joe Friedeggs
Re-posting minus the garbage....
>> Debugging this issue has caused me a bit of confusion. In the LDAP logs, when logging into other equipment that 'binds as user', I see warnings, etc. returned:
>>
>> ppolicy_bind: Setting warning for password expiry for uid=test_user,ou=people,o=theorg,dc=example,dc=net = 1251 secds
>>
>> BUT, since the Linux LDAP client has a separate 'binddn', I don't see these warnings when the Linux LDAP client does the ldapsearch to validate the user. How does the policy work in this situation?
>>
>> Am I missing something here?
>>
>
> Hello,
>
> have a look at 'man pam_ldap':
>
> <snip>
>> pam_lookup_policy <yes|no>
>> Specifies whether to search the root DSE for password policy. The default is "no".
> <snap>
>
> Did you set that to yes on your clients in /etc/ldap.conf or what ever
> it is called on RHEL5?
>
>
> Regards,
> Christian Manal
Thanks for the response, Christian.
Yes, I have the following in my clients' /etc/ldap.conf:
host ldap_svc
binddn cn=simpleBind,o=theorg,dc=example,dc=net
bindpw simpleBind
bind_timelimit 3
base o=theorg,dc=example,dc=net
sudoers_base ou=sudoers,o=theorg,dc=example,dc=net
timelimit 7
idle_timelimit 3600
nss_base_passwd ou=people,o=theorg,dc=example,dc=net?one
nss_base_shadow ou=people,o=theorg,dc=example,dc=net?one
nss_base_group ou=groups,o=theorg,dc=example,dc=net?one
nss_reconnect_tries 3
nss_initgroups_ignoreusers root,ldap,named,haldaemon,radiusd,linux_admin
pam_password md5
pam_groupdn cn=level_3,ou=host_ssh_access,o=theorg,dc=example,dc=net
pam_member_attribute uniqueMember
pam_lookup_policy yes
Thanks,
Joe
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:1;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:variable;
mso-font-signature:0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-1610611985 1073750091 0 0 159 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-noshow:yes;
mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.5pt;
font-family:Consolas;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-bidi-font-family:"Times New Roman";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:"Plain Text";
mso-ansi-font-size:10.5pt;
mso-bidi-font-size:10.5pt;
font-family:Consolas;
mso-ascii-font-family:Consolas;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Consolas;
mso-bidi-font-family:"Times New Roman";}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:...
11 years, 2 months
ppolicy and Red Hat Linux
by Joe Friedeggs
I need help/advise on ppolicy against Linux servers.
I am running OpenLDAP 2.3.43-3.el5 (Red Hat rpm) on RHEL5. I am using the ppolicy overlay. The overlay seems to work to all of the tools, etc., that use this LDAP, except for the Linux servers. With these servers, we get no expiry warning, and users can log in after the password has expired (unlimited). We are using PAM/LDAP on these servers.
Debugging this issue has caused me a bit of confusion. In the LDAP logs, when logging into other equipment that 'binds as user', I see warnings, etc. returned:
ppolicy_bind: Setting warning for password expiry for uid=test_user,ou=people,o=theorg,dc=example,dc=net = 1251 secds
BUT, since the Linux LDAP client has a separate 'binddn', I don't see these warnings when the Linux LDAP client does the ldapsearch to validate the user. How does the policy work in this situation?
Am I missing something here?
Here's what I see when I log in as a users (second login, pwdGraceAuthNLimit=2):
login as: test_user
test_user@linux_box's password:
Last login: Fri Oct 23 19:39:03 2009 from 10.50.1.135
[test_user@linux_box ~]$
[test_user@linux_box ~]$ ldapwhoami -x -D "uid=test_user,ou=people,o=theorg,dc=example,dc=net" -W -e ppolicy
Enter LDAP Password:
ldap_bind: Success (0) (Password expired, 1 grace logins remain)
dn:uid=test_user,ou=people,o=theorg,dc=example,dc=net
Result: Success (0)
[test_user@linux_box ~]$
[test_user@linux_box ~]$exit
Then on the next login:
login as: test_user
test_user@linux_box's password:
Last login: Fri Oct 23 19:39:26 2009 from 10.50.1.135
[test_user@linux_box ~]$
[test_user@linux_box ~]$ ldapwhoami -x -D "uid=test_user,ou=people,o=theorg,dc=example,dc=net" -W -e ppolicy
Enter LDAP Password:
ldap_bind: Invalid credentials (49); Password expired
[test_user@linux_box ~]$
[test_user@linux_box ~]$exit
Yet again:
login as: test_user
test_user@linux_box's password:
Last login: Fri Oct 23 19:40:12 2009 from 10.50.1.135
[test_user@linux_box ~]$
[test_user@linux_box ~]$ ldapwhoami -x -D "uid=test_user,ou=people,o=theorg,dc=example,dc=net" -W -e ppolicy
Enter LDAP Password:
ldap_bind: Invalid credentials (49); Password expired
[test_user@linux_box ~]$
[test_user@linux_box ~]$
[test_user@linux_box ~]$
[test_user@linux_box ~]$ ldapsearch -x -D 'cn=ldapmanager,o=theorg,dc=example,dc=net' -b 'uid=test_user,ou=people,o=theorg,dc=example,dc=net' -w ldapspwd +
# extended LDIF
#
# LDAPv3
# base <uid=test_user,ou=people,o=theorg,dc=example,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: +
#
# test_user, people, theorg, example.net
dn: uid=test_user,ou=people,o=theorg,dc=example,dc=net
structuralObjectClass: person
entryUUID: d45aa296-a3e4-102d-8c8e-0b16af70e85f
creatorsName: cn=ldapmanager,o=theorg,dc=example,dc=net
createTimestamp: 20090313063503Z
pwdHistory: 20091023185344Z#1.3.6.1.4.1.1466.115.121.1.40#41#{crypt}$1$RCW90SL
v$8PfQ99gzlJd.7TH2HnhOS0
pwdHistory: 20091023190836Z#1.3.6.1.4.1.1466.115.121.1.40#41#{crypt}$1$RM6V/En
e$0oGsI47SUaIDFap9Nft3z1
pwdHistory: 20091023191529Z#1.3.6.1.4.1.1466.115.121.1.40#41#{crypt}$1$18vC.s9
3$cT38cSrrF/PXMhWqV.P.r/
pwdPolicySubentry: cn=ppdefault_test,ou=policies,o=theorg,dc=example,
dc=net
pwdChangedTime: 20091023191529Z
pwdGraceUseTime: 20091023193816Z
pwdGraceUseTime: 20091023193905Z
entryCSN: 20091023193905Z#000000#00#000000
modifiersName: cn=ldapmanager,o=theorg,dc=example,dc=net
modifyTimestamp: 20091023193905Z
entryDN: uid=test_user,ou=people,o=theorg,dc=example,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[test_user@linux_box ~]$
[test_user@linux_box ~]$ ldapsearch -x -D 'cn=ldapmanager,o=theorg,dc=example,dc=net' -b 'cn=ppdefault_test,ou=policies,o=theorg,dc=example,dc=net' -w ldapspwd
# extended LDIF
#
# LDAPv3
# base <cn=ppdefault_test,ou=policies,o=theorg,dc=example,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ppdefault_test, policies, theorg, example.net
dn: cn=ppdefault_test,ou=policies,o=theorg,dc=example,dc=net
cn: ppdefault_test
objectClass: person
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
pwdAttribute: userPassword
pwdLockout: TRUE
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdGraceAuthNLimit: 2
pwdCheckQuality: 1
pwdInHistory: 3
pwdLockoutDuration: 60
pwdMaxFailure: 5
pwdFailureCountInterval: 603
sn: ppdefault_test
pwdMaxAge: 120
pwdExpireWarning: 100
description: test
pwdMinAge: 1
pwdSafeModify: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[test_user@linux_box ~]$
[test_user@linux_box ~]$ cat /etc/pam.d/passwd
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
[test_user@linux_box ~]$
[test_user@linux_box ~]$ 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 /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 type=LDAP
password sufficient /lib/security/$ISA/pam_unix.so nullok md5 use_authtok shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so
Any advise would be much appreciated (I swear this worked when I tested it last March).
Thanks,
Joe
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:...
11 years, 2 months
Using Arbitrary X509 certificates for LDAPS authentication
by Stephen Cartwright
Hi there,
Are there any restrictions on the DN or other attributes of
credentials used for LDAP authentication?
We are using grid credentials (X509 format) with DNs like this:
issuer= /C=CA/O=Grid/CN=Grid Canada Certificate Authority
subject= /C=CA/O=Grid/CN=host/somehost.somedomain.ca
When I use some grid certs (X509 format) I see this message in the debug
output from slapd:
connection_read(10): unable to get TLS client DN error=49 id=3
When I try to connect, I get this:
ldap_initialize( ldaps://somehost.somedomain.ca )
ldap_bind: Can't contact LDAP server
The openssl command to create a connection works OK:
CONNECTED(00000003)
---
Certificate chain
0 s:/C=CA/O=Grid/CN=host/somehost.somedomain.ca
i:/C=CA/O=Grid/CN=Grid Canada Certificate Authority
1 s:/C=CA/O=Grid/CN=Grid Canada Certificate Authority
i:/C=CA/O=Grid/CN=Grid Canada Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=CA/O=Grid/CN=host/somehost.somedomain.ca
issuer=/C=CA/O=Grid/CN=Grid Canada Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 2083 bytes and written 320 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID:
43B46528E848663E7C8E9CAAEA4E6DB5E4A9675C05C3066DBD826CD1CF59A566
Session-ID-ctx:
Master-Key:
A8245A0731BA98F0D88821346432868C392FEE3F23EAFB9F356A34CB6BB663FC0892374118F280D6284C8E2ACAC3
Key-Arg : None
Start Time: 1251330160
Timeout : 300 (sec)
Verify return code: 0 (ok)
When I use certs created by us with another DN format such as this:
subject= /C=CA/ST=Province/L=Town/O=Organization/OU=Unit/CN=somehost.somedomain.ca/emailAddress=email(a)somewhere.ca
issuer= /C=CA/ST=Province/O=Organization/OU=Town/CN=Our
CA/emailAddress=email(a)somewhere.ca
And then make no other changes to the config other than pointing
everything to the new commands I can make a connection.
Any suggestions? Please advise.
Steve
11 years, 2 months
ldapsearch vs AD output
by Cherubini Enrico
Good day,
hope to be not OT. I have to get members of a group in AD, so here is what I
do and what I get:
ldapsearch -x -D "pippo(a)dominio.com" -w pippopw "cn=groupname"
member:: W049X1MgVmlhPPAaXTDoCxPVT1fQSBNYW51dGOOOemlvbmUgZSBHZXN0aW9uZSBQYX=
Rya
W1vbmlvLERDPXByb3ZpbmNpYSxEQz12cixEQz1pdA=3D=3D
member: CN=_SubGroup2,OU=_SubGroupArea,DC=dominio,DC=com
If I do a search whith phpldapadmin I get both name (_SubGroup1 and
_SubGroup2), so I guess the problem is how ldapsearch handles the output
from AD server or in config file, but can't find a solution.
Any hint ?
TIA
11 years, 2 months
2.3.43 master to 2.4.18 slave problem
by Bill MacAllister
I have hit a replication problem that I am scratching my head over.
We are in the midst of migrating from OpenLDAP from 2.3 to 2.4. In
our test environment we have a 2.3.43 master with 2.4.18 and 2.3.35
slaves. Replication to the 2.4 slave stopped this morning. When I
look at the log I see:
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000000#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: rid=000 CSN too old, ignoring 20091022031949.000000Z#000000#000#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000001#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: rid=000 CSN too old, ignoring 20091022031949.000000Z#000001#000#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000002#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: rid=000 CSN too old, ignoring 20091022031949.000000Z#000002#000#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000003#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: rid=000 CSN too old, ignoring 20091022031949.000000Z#000003#000#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000004#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: rid=000 CSN too old, ignoring 20091022031949.000000Z#000004#000#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: do_syncrep2: cookie=csn=20091022031949Z#000005#00#000000,rid=000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: slap_queue_csn: queing 0x7f09c283b075 20091022031949Z#000005#00#000000
Oct 22 09:38:28 ldap-uat1 slapd[15032]: syncrepl_message_to_op: rid=000 mods check (homePostalAddress: value #0 invalid per syntax)
Oct 22 09:38:28 ldap-uat1 slapd[15032]: slap_graduate_commit_csn: removing 0x7f09c1621438 20091022031949Z#000005#00#000000
So, I slapcat'ed the master's database and looked for that contextCSN.
The entry that appears to be the problem has a homePostalAddress of:
homePostalAddress: c\o Bain & Company, Two Copley Place, Boston, Massachusetts
We had hit this problem before when loading a 2.4 server using slapcat
output from a 2.3 server and wrote a simple filter to correctly quote
the backslash.
This is a problem for us because we expect to have a mixed 2.3/2.4 during
the transistion to 2.4 on our production servers. The really nasty bit is
that the only way I know for sure to fix this problem is to reload the
slave. Is there an alterntive way?
Bill
--
Bill MacAllister, System Software Programmer
Unix Systems Group, Stanford University
11 years, 2 months
shadow context; no update referral
by Venish Khant
I had configured openldap in master/slave for replication. It's work
perfectly. It's replicated entries but one entry not replicated. I try
to add that entry using ldapadd command in my slave server. That time I
got the below error.
adding new entry "uid=test,ou=people,dc=example,dc=com"
ldap_add: Server is unwilling to perform (53)
additional info: shadow context; no update referral
--
Venish Khant
www.deeproot.co.in
11 years, 2 months
LDAP Monitoring CN=Monitor
by Andreas Andersson
Hi!
My name is Andreas and I want to inform you about a little project
I've been working on called CN=Monitor.
It's about monitoring and verifying directory servers with focus on
open source LDAP servers. From single installed servers to large
scaled deployments.
Its a webbased application where you can:
* Verify availability, compare load and performance between servers
* Collect historical events for long term analysis (and get weekly
reports by mail)
* Verify cluster and load balancing functionality
* Query several directories at the same time for data consistancy
verification
... and a lot more.
Why the name CN=Monitor. Well.. a lot of the information collected and
analyzed is gathered from the CN=Monitor base DN.
Project page:
http://cnmonitor.sourceforge.net
Freshmeat:
http://freshmeat.net/projects/cnmonitor
I appreciate all feedback I can get so let me know if there are any
features you are missing or other things that can improve the
application.
Replication and cache monitoring is currently only available for 389
DS. Hopefully this can be added for OpenLDAP in the future.
Best regards - Andreas Andersson
11 years, 2 months
OpenLDAP/TLS+SASL (mech: EXTERNAL) with JNDI
by Stefan Jurisch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I am implementing a custom Java LDAP library for our custom needs, and
now I am at the point where I have to write the methods for a TLS
authentication.
I am searching for a solution since yesterday in the morning, but
nothing matched. All found standard examples break with more or less
heavy exceptions.
I must connect to an OpenLDAP 2.4.x with complete TLS/SASL
authentication, meaning the same thing like
ldapsearch -T EXTERNAL -ZZ [...]
It works well with my certs on CLI, but all tested Java implementations
did not work properly yet.
The best result I get at the moment, where I receive *only* one exception:
[...]
LDAP server connection URL:
ldap://kungfu.in.siegnetz.de:389/dc=kungfu-local,dc=net
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 7 -
SASL(-4): no mechanism available: ]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3032)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2602)
at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3156)
at
javax.naming.ldap.InitialLdapContext.extendedOperation(InitialLdapContext.java:164)
at
de.siegnetz.ldaptools.connection.LDAPServerConnection.open(LDAPServerConnection.java:295)
at de.siegnetz.test.SomeLdapTests.ldap_test1(SomeLdapTests.java:29)
at de.siegnetz.test.SomeLdapTests.main(SomeLdapTests.java:13)
dn: uid=dkent,ou=users,ou=Siegen,dc=kungfu-local,dc=net
sambaPrimaryGroupSID: S-1-5-21-3205579064-1077270308-3928157200-513
sambaDomainName: KUNGFU-NET
displayName: Kent, Dark (the sincerly unknown evil twin)
givenName: Dark
[...]
where the interesting thing is, that, as you can see, the searchresult
of the JNDI request is printed out, broke by the exception.
TLS section in slapd.conf looks like this:
TLSCertificateFile /etc/openldap/certs/kungfu-cert.pem
TLSCertificateKeyFile /etc/openldap/certs/kungfu-key.pem
TLSCACertificateFile /etc/openldap/certs/kungfu_ca.pem
TLSVerifyClient demand
I try to use it with a TinyCA2 created cert with 4096Bit RSA, exported
as [...].pem cert and key files for the client + the ca.cert and the
server cert and key.
Is there perhaps a special X509 format that has to be used? Or are there
other traps when using Java and OpenLDAP?
I first used the library found here on the page, but I thought it would
not fit my needs, because it did neither not work properly.
Is there anyone out there who can help me on that issue?
Thanks in advance and best regards
Stefan
- --
S T E F A N J U R I S C H
- --------------------------------
System Engineer - VMware Support
SIEGNETZ.IT GmbH
Schneppenkauten 1a
D-57076 Siegen
Tel. +49 271 68193- 0
Fax: +49 271 68193-28
http://www.siegnetz.de
Amtsgericht Siegen HRB4838
Geschäftsführer: Oliver Seitz
Sitz der Gesellschaft ist Siegen
- --------------------------------
Das Wort "WINDOWS" stammt aus
einem alten Sioux-Dialekt und
bedeutet:
"Weißer Mann starrt durch
Glasscheibe auf Sanduhr."
- --------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkrgD8AACgkQqdb99cbyCz4fMACdEG25Vo2LCTN+jZbX4dDIEtYs
qGkAn2iDEQ7j9fO1oEb4RrXaOVpXLJPz
=Jks5
-----END PGP SIGNATURE-----
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11 years, 2 months
why didn't ldap client validate ssl certificate?
by leilei175@gmail.com
hi,
I have a question on using tls on ldap.
Hopefully anybody could give a hint on this.
On the client side,I have set the TLS_REQCERT as demand.
The TLS_CACERTDIR is also set, but I didn't put any certificate in the
directory.
To my surprise, even though no certificate is provided,
ldapsearch could still succeed returning the data.
Is this a bug?
the openldap is running on redhat enterprise linux 4, openldap version is
openldap-servers-sql-2.2.13-12.el4
openldap-servers-2.2.13-12.el4
openldap-devel-2.2.13-12.el4
openldap-2.2.13-12.el4
openldap-clients-2.2.13-12.el4
Any idea is appreciated!
Thanks
lei
11 years, 2 months
bug report "ldap_simple_bind_s"
by cress
A backend daemon using openldap was frequently halted, The problem was
finally located at an openldap function ldap_simple_bind_s. Below is a trace
back of the running system:
#0 0x00a0c7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x004e0b24 in poll () from /lib/tls/libc.so.6
#2 0x00ab8128 in ldap_int_select (ld=0x1, timeout=0x0) at os-ip.c:983
#3 0x00aa7f5f in wait4msg (ld=0x8f0a2c0, msgid=21, all=1, timeout=0x0,
result=0x36fc1c4) at result.c:355
#4 0x00aa7b32 in ldap_result (ld=0x8f0a2c0, msgid=21, all=1, timeout=0x0,
result=0x36fc1c4) at result.c:127
#5 0x00aad5d2 in ldap_sasl_bind_s (ld=0x8f0a2c0, dn=0x36fc260
"uid=chenming,domain=vip.eyou.net,o=vip.eyou.net",
mechanism=0x0, cred=0x36fc208, sctrls=0x0, cctrls=0x0, servercredp=0x0)
at sasl.c:194
#6 0x00aadc74 in ldap_simple_bind_s (ld=0x8f0a2c0, dn=0x36fc260
"uid=chenming,domain=vip.eyou.net,o=vip.eyou.net",
passwd=0x36fca4a "") at sbind.c:113
#7 0x003ab2b0 in eyou_db_alias_auth (pdbh=0x36fd3a8, uid=0x8efd8a0
"chenming", domain=0x8efd8c1 "vip.eyou.net",
password=0x36fca40 "xxxxxxxxx", alias=0x36fc5c0 "") at
ldap/eyou_db.c:153
#8 0x003ab1ae in eyou_db_real_auth (dh=0x36fd3a8, uid=0x8efd8a0 "chenming",
domain=0x8efd8c1 "vip.eyou.net",
password=0x36fca40 "xxxxxxxxx", realuid=0x36fc5c0 "",
realdomain=0x36fc570 "") at ldap/eyou_db.c:123
#9 0x003c7669 in get_user_info_by_ldap (uid=0x8efd8a0 "chenming",
domain=0x8efd8c1 "vip.eyou.net", userinfo=0x8efbd18,
edbh=0x36fd3a8, password=0x36fca40 "xxxxxxxxx") at utils/user_info.c:559
#10 0x003c5cd9 in get_user_info (edbh=0x36fd3a8, uid=0x8efd8a0 "chenming",
domain=0x8efd8c1 "vip.eyou.net",
password=0x36fca40 "xxxxxxxxx", userinfo=0x8efbd18) at
utils/user_info.c:160
#11 0x003a18da in user_validate (edbh=0x36fd3a8, uid=0x8efd8a0 "chenming",
domain=0x8efd8c1 "vip.eyou.net",
pass=0x36fca40 "chenkane1", userinfo=0x8efbd18) at
utils/user_validate.c:61
#12 0x0804b6f2 in pop3_pass (arg=0x36fce80 "xxxxxxxxx", fun_arg=0x8efd8a0)
at pop3_protocol.c:363
#13 0x0804d41a in new_commands (eio_fp=0x8f15cb8, tls_start=0, ssl=0x0,
c=0x36fd2e0, fun_arg=0x8efd8a0) at commands.c:63
#14 0x0804ad94 in eyou_pop3 (eyou_db_hander=0x36fd3a8,
eyou_socket_hander=0x8eff7e8) at pop3d.c:138
#15 0x08050470 in net_deliver (arg=0x8eef300) at gaea/deliver.c:219
#16 0x00b873cc in start_thread () from /lib/tls/libpthread.so.0
#17 0x004ea96e in clone () from /lib/tls/libc.so.6
The problem may be in the lines with red marked, However, this should not
cause the program be halted。
Can i resolve the problem by set a timeout with openldap ?And how to do ?
11 years, 2 months