Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao@computer.org
Thanks for the heads-up Quanah. Looks like you've found a serious
problem with multi-master replication, good to know about. In my case,
we're just using single-master replication, so we're able to dodge the
problem you describe for the time being.
Just to clarify though -- once ITS#8125 is resolved, this enhancement
shouldn't pose any additional problems for MMR sites, right?
Thanks,
-Kartik
On 07/06/2015 12:18 PM, Quanah Gibson-Mount wrote:
> I would note that:
>
> IF using delta-syncrepl
> AND the data values are replicated
> AND authentication attempts can occur against different LDAP masters
>
> You can run into *serious* drift between servers if you try and
> implement this, causing endless refresh mode runs that cause the
> servers to get further out of sync. See
> <http://www.openldap.org/its/index.cgi/?findid=8125>.
>
> More specifically:
>
> If a client has (most often) a mobile device with a bad password, and
> it's authentication attempts are bouncing between masters, even with
> high resolution timestamps, you can get collisions in the delete op
> for old values that cannot be reconciled, causing fallback/refresh.
>
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
7 years, 11 months
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao@computer.org
This is a multi-part message in MIME format.
--------------000605000401060905080908
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 07/06/2015 12:25 PM, Michael Ströder wrote:
> Hmm, still have some doubts: If you want to raise the failure count limit
> later you would automatically unlock some accounts you don't want to unlock at this particular point in time.
Two thoughts on this:
1) If you raise the failure count limit, aren't you inherently making a
decision to be more lenient in your policy, and thereby accepting that
some accounts are not going to be locked out as fast as they might be
under the previous policy? It seems to me that any "inadvertent"
unlocking due to purged pwdFailureTime values could be embraced under
this general umbrella of leniency.
2) If pwdFailureCountInterval is set to some reasonably low number, then
this whole concern becomes moot: Just wait for pwdFailureCountInterval
seconds after you decide to change the configuration, before actually
changing the configuration :-)
I guess I haven't come across many sites that set pwdMaxFailure, but
/don't/ also set pwdFailureCountInterval. But even in those cases, I
think #1 would be valid :-)
Regards,
-Kartik
--------------000605000401060905080908
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/06/2015 12:25 PM, Michael Ströder
wrote:<br>
</div>
<blockquote cite="mid:559AABDC.8060706@stroeder.com" type="cite">
<pre wrap="">
Hmm, still have some doubts: If you want to raise the failure count limit
later you would automatically unlock some accounts you don't want to unlock at this particular point in time.
</pre>
</blockquote>
<br>
Two thoughts on this:<br>
<br>
1) If you raise the failure count limit, aren't you inherently
making a decision to be more lenient in your policy, and thereby
accepting that some accounts are not going to be locked out as fast
as they might be under the previous policy? It seems to me that any
"inadvertent" unlocking due to purged pwdFailureTime values could be
embraced under this general umbrella of leniency.<br>
<br>
2) If pwdFailureCountInterval is set to some reasonably low number,
then this whole concern becomes moot: Just wait for
pwdFailureCountInterval seconds after you decide to change the
configuration, before actually changing the configuration :-)<br>
<br>
I guess I haven't come across many sites that set pwdMaxFailure, but
<i>don't</i> also set pwdFailureCountInterval. But even in those
cases, I think #1 would be valid :-)<br>
<br>
Regards,<br>
<br>
-Kartik<br>
</body>
</html>
--------------000605000401060905080908--
7 years, 11 months
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao@computer.org
This is a multi-part message in MIME format.
--------------070603090603020704050207
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
FYI for anyone else who is encountering this problem -- here is a script
that I wrote as a workaround. It sweeps through all of the
pwdFailureTime entries in the directory and deletes stale values greater
than $maxvalues. Also set $basedn accordingly.
It can be run with '--ldif' to preview the changes, and '--ldap' to
actually make the changes.
The script binds with SASL EXTERNAL on the ldapi:/// interface, so make
sure that the Unix user has the 'manage' privilege for the
pwdFailureTime attribute. For example, to enable this for root:
access to attrs=pwdFailureTime by
dn.base="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" manage
Regards,
-Kartik
--------------070603090603020704050207
Content-Type: text/plain; charset=UTF-8;
name="pwdfailuretime.pl.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="pwdfailuretime.pl.txt"
IyEgL3Vzci9iaW4vcGVybAoKIyBQdXJnZSBzdGFsZSBwd2RGYWlsdXJlVGltZSB2YWx1ZXMK
CnVzZSBOZXQ6OkxEQVA7CnVzZSBOZXQ6OkxEQVA6OkNvbnRyb2w7CnVzZSBOZXQ6OkxEQVA6
OkxESUY7CnVzZSBBdXRoZW46OlNBU0w7CnVzZSBGY250bCBxdyhMT0NLX0VYIExPQ0tfTkIp
Owp1c2UgR2V0b3B0OjpMb25nOwoKdXNlIHN0cmljdDsKCm15ICRiYXNlZG4gPSAiZGM9ZXhh
bXBsZSxkYz1jb20iOwpteSAkbWF4dmFsdWVzID0gMTA7CgojIFByZXZlbnQgbXVsdGlwbGUg
aW5zdGFuY2VzIGZyb20gcnVubmluZyBhdCB0aGUgc2FtZSB0aW1lCm9wZW4oTE9DS0ZILCAk
MCk7IGZsb2NrKExPQ0tGSCwgTE9DS19FWHxMT0NLX05CKSBvciBleGl0IDE7CgpteSAoJGdl
bmVyYXRlX2xkaWYsICR1cGRhdGVfbGRhcCk7CkdldE9wdGlvbnMoJ2xkaWYnID0+IFwkZ2Vu
ZXJhdGVfbGRpZiwgJ2xkYXAnID0+IFwkdXBkYXRlX2xkYXApOwoKbXkgJGxkaWZvdXQgPSBO
ZXQ6OkxEQVA6OkxESUYtPm5ldygnLScsICd3Jyk7CiRsZGlmb3V0LT57Y2hhbmdlfSA9IDE7
Cm15ICRsZGFwID0gTmV0OjpMREFQLT5uZXcoJ2xkYXBpOi8vJykgb3IgZGllICJsZGFwaTog
JEBcbiI7Cm15ICRzYXNsID0gQXV0aGVuOjpTQVNMLT5uZXcobWVjaGFuaXNtID0+ICdFWFRF
Uk5BTCcpOwpteSAkc2FzbF9jbGllbnQgPSAkc2FzbC0+Y2xpZW50X25ldygnbGRhcCcsICds
b2NhbGhvc3QnKTsKJGxkYXAtPmJpbmQodW5kZWYsIHNhc2wgPT4gJHNhc2xfY2xpZW50KTsK
bXkgJHJlbGF4ID0gTmV0OjpMREFQOjpDb250cm9sLT5uZXcodHlwZSA9PiAnMS4zLjYuMS40
LjEuNDIwMy42NjYuNS4xMicpOwoKbXkgJG1lc2cgPSAkbGRhcC0+c2VhcmNoKGJhc2UgPT4g
JGJhc2VkbiwKCQkJCQkJIGZpbHRlciA9PiAnKHB3ZEZhaWx1cmVUaW1lPSopJywKCQkJCQkJ
IGF0dHJzID0+IFsncHdkRmFpbHVyZVRpbWUnXSk7CiRtZXNnLT5jb2RlICYmIGRpZSgkbWVz
Zy0+ZXJyb3IgLiAiXG4iKTsKZm9yZWFjaCBteSAkZW50cnkgKCRtZXNnLT5lbnRyaWVzKSB7
CglteSBAdmFsdWVzID0gc29ydCAkZW50cnktPmdldF92YWx1ZSgncHdkRmFpbHVyZXRpbWUn
KTsKCW5leHQgaWYgQHZhbHVlcyA8PSAkbWF4dmFsdWVzOwoJIyBTZXQgQHZhbHVlcyB0byB0
aGUgbGlzdCBvZiB2YWx1ZXMgdG8gcHVyZ2UKCXNwbGljZSBAdmFsdWVzLCAtJG1heHZhbHVl
czsKCWlmICgkZ2VuZXJhdGVfbGRpZikgewoJCSRlbnRyeS0+ZGVsZXRlKCdwd2RGYWlsdXJl
dGltZScgPT4gXEB2YWx1ZXMpOwoJCSRsZGlmb3V0LT53cml0ZV9lbnRyeSgkZW50cnkpOwoJ
fQoJaWYgKCR1cGRhdGVfbGRhcCkgewoJCSRsZGFwLT5tb2RpZnkoJGVudHJ5LT5kbiwKCQkJ
CQkgIGNvbnRyb2wgPT4gJHJlbGF4LAoJCQkJCSAgZGVsZXRlID0+IHsgcHdkRmFpbHVyZXRp
bWUgPT4gXEB2YWx1ZXMgfSk7Cgl9Cn0K
--------------070603090603020704050207--
7 years, 11 months
Re: (ITS#8189) autoconf needed when building release
by michael@stroeder.com
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for Berkeley DB major version in db.h... none
configure: error: Unknown Berkeley DB major version in db.h
>From config.log:
configure:20300: checking db.h usability
configure:20300: cc -c -g -O0 -DSLAP_SCHEMA_EXPOSE
-DLDAP_COLLECTIVE_ATTRIBUTES -DSLAP_CONFIG_DELETE -I/usr/include
-I/usr/include -I/usr/include -I/usr/include conftest.c >&5
configure:20300: $? = 0
configure:20300: result: yes
configure:20300: checking db.h presence
configure:20300: cc -E -I/usr/include -I/usr/include -I/usr/include
-I/usr/include conftest.c
configure:20300: $? = 0
configure:20300: result: yes
configure:20300: checking for db.h
configure:20300: result: yes
configure:20311: checking for Berkeley DB major version in db.h
configure:20331: result: none
configure:20334: error: Unknown Berkeley DB major version in db.h
7 years, 11 months
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael@stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms000206000000020208060300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Kartik Subbarao wrote:
> You mention that "pwdFailureTime is also used as a failure lockout coun=
ter". I
> don't see how that conflicts with what I am requesting. I'm only asking=
for
> /excess/ pwdFailureTime values that are above the pwdMaxFailure count t=
o be
> purged.
Oh, I see. Indeed I did not fully understand your original message.
> For example, if pwdMaxFailure is 3, and pwdFailureTime has the
> following values:
>=20
> pwdFailureTime: 20150702184821Z
> pwdFailureTime: 20150702185821Z
> pwdFailureTime: 20150702190822Z
> pwdFailureTime: 20150702191007Z
> pwdFailureTime: 20150702191012Z
>=20
> What I'm requesting is that the /oldest/ two values be deleted from thi=
s set:
Hmm, still have some doubts: If you want to raise the failure count limit=
later you would automatically unlock some accounts you don't want to unlo=
ck at
this particular point in time.
Ciao, Michael.
--------------ms000206000000020208060300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG
9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw
NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG
A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4
uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk
Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK
JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih
34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v
KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj
z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf
BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL
KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0
byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22
A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm
v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3
6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq
YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw
oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwNjE2MjUwMFowLwYJKoZIhvcNAQkEMSIE
IH7+cZbIVOCGL55ZjKKaUB/HHprnj2PhEJuxySRq8xP/MGwGCSqGSIb3DQEJDzFfMF0wCwYJ
YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB
lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ
EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG
A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh
cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq
hkiG9w0BAQEFAASCAQAYG+byNJRgIHP9toZH8tn2UbQgnS24FVS+UMsGsFfpaITB5HECe9wH
hJnCbzGUBE7YIXOKXCqSPbv5O+p9oj8IfP9Go80R8Gemrx3/MdnaxGGBDkvBLLlyrRhvVfTm
a0MKEuwXrTMeAmf33hmAeMtJxdYJj8ibRO4HWf1rsivzIjnvyajdVvCjEWKhHk8l5u6D3icw
7ufZtt6B49R3gaYaE072rp+5r9iENwgwF60RacNGTMfjtSlNCN3WHEbIq9Eys1EZ5BKaBc44
VcYKDP1zoqe4QXoxxJ85uFySM6AScLAod0el8Z9GXNwe7m795l6lIgeY0dye7HBTWMJUteTD
AAAAAAAA
--------------ms000206000000020208060300--
7 years, 11 months
(ITS#8189) autoconf needed when building release
by michael@stroeder.com
Full_Name:
Version: 2.4.41
OS:
URL:
Submission from: (NULL) (79.223.59.125)
It's currently necessary to run autoconf before configure to build with
gcc-5.1.1. Otherwise cpp is not invoked with -P and thus the Berkeley DB check
fails.
7 years, 11 months
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by quanah@zimbra.com
--On Monday, July 06, 2015 5:12 PM +0000 subbarao(a)computer.org wrote:
> This is a multi-part message in MIME format.
> --------------060309030709060507050000
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi Michael,
>
> I'm having a bit of difficulty understanding your response, and it looks
> like my initial message was perhaps equally as unclear to you :-) Let me
> try to clarify, please let me know if this still doesn't make sense.
>
> You mention that "pwdFailureTime is also used as a failure lockout
> counter". I don't see how that conflicts with what I am requesting. I'm
> only asking for /excess/ pwdFailureTime values that are above the
> pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3,
> and pwdFailureTime has the following values:
>
> pwdFailureTime: 20150702184821Z
> pwdFailureTime: 20150702185821Z
> pwdFailureTime: 20150702190822Z
> pwdFailureTime: 20150702191007Z
> pwdFailureTime: 20150702191012Z
I would note that:
IF using delta-syncrepl
AND the data values are replicated
AND authentication attempts can occur against different LDAP masters
You can run into *serious* drift between servers if you try and implement
this, causing endless refresh mode runs that cause the servers to get
further out of sync. See
<http://www.openldap.org/its/index.cgi/?findid=8125>.
More specifically:
If a client has (most often) a mobile device with a bad password, and it's
authentication attempts are bouncing between masters, even with high
resolution timestamps, you can get collisions in the delete op for old
values that cannot be reconciled, causing fallback/refresh.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 11 months
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao@computer.org
This is a multi-part message in MIME format.
--------------060309030709060507050000
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Michael,
I'm having a bit of difficulty understanding your response, and it looks
like my initial message was perhaps equally as unclear to you :-) Let me
try to clarify, please let me know if this still doesn't make sense.
You mention that "pwdFailureTime is also used as a failure lockout
counter". I don't see how that conflicts with what I am requesting. I'm
only asking for /excess/ pwdFailureTime values that are above the
pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3,
and pwdFailureTime has the following values:
pwdFailureTime: 20150702184821Z
pwdFailureTime: 20150702185821Z
pwdFailureTime: 20150702190822Z
pwdFailureTime: 20150702191007Z
pwdFailureTime: 20150702191012Z
What I'm requesting is that the /oldest/ two values be deleted from this
set:
pwdFailureTime: 20150702184821Z
pwdFailureTime: 20150702185821Z
(To be more precise, I'll suggest that when ppolicy_bind_response()
processes the BIND failure that triggers the addition of 20150702191012Z
to pwdFailureTime, that's when it could delete the two oldest values. It
already loops through the entire set of pwdFailureTime values, so adding
a check to delete older ones above the pwdMaxFailure count could be done
in that same loop).
I'm not seeing how this would conflict with the password policy
specification -- am I missing something?
In the particular situation that's prompting this request, it's not just
two or three values -- for one entry it was over 38000 values that had
accumulated over time! (and generally high values for many other entries).
ITS#7161 doesn't address this issue -- it adds more precision to the
timestamp values, but it doesn't purge excess stale values.
Here's how this issue relates to ITS#7089. In ITS#7089, the requester
was seeing failed bind attempts to entries that didn't have a password
defined. As a result, pwdFailureTime values were consistently being
added to these entries. The common theme is that there is no built-in
way (to my knowledge) in OpenLDAP to protect against pwdFailureTime
values continually being added to entries indefinitely.
This enhancement would mitigate that problem by putting a cap on the
number of pwdFailureTime attributes that could ever accumulate on an
entry -- the pwdMaxFailure count. Just like administrators have control
over expiring old log files, they would get the ability to ensure that
pwdFailureTime values couldn't accumulate indefinitely.
Please let me know what you think.
Thanks,
-Kartik
Michael Stroeder wrote:
>> This wording in the slapo-ppolicy man page sounds friendly towards this
>> interpretation: "Excess timestamps beyond those allowed by
pwdMaxFailure
>> may also be purged."
>>
>> Looking at the source code though, it doesn't seem that pwdFailureTime
>> values are actually removed unless a successful bind occurs --
whereupon
>> all values of course are removed.
>>
>> I would like to request an enhancement to purge stale pwdFailureTime
>> values as mentioned above.
>
> Nope. The number of pwdFailureTime is also used as failure lockout
> counter. Actually it was improved with ITS#7161.
>
>> This would also largely mitigate the issue raised in ITS#7089
>
> I don't see the relation with ITS#7089.
--------------060309030709060507050000
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Michael,<br>
<br>
I'm having a bit of difficulty understanding your response, and it
looks like my initial message was perhaps equally as unclear to you
:-) Let me try to clarify, please let me know if this still doesn't
make sense.<br>
<br>
You mention that "pwdFailureTime is also used as a failure lockout
counter". I don't see how that conflicts with what I am requesting.
I'm only asking for <i>excess</i> pwdFailureTime values that are
above the pwdMaxFailure count to be purged. For example, if
pwdMaxFailure is 3, and pwdFailureTime has the following values:<br>
<br>
pwdFailureTime: 20150702184821Z<br>
pwdFailureTime: 20150702185821Z<br>
pwdFailureTime: 20150702190822Z<br>
pwdFailureTime: 20150702191007Z<br>
pwdFailureTime: 20150702191012Z<br>
<br>
What I'm requesting is that the <i>oldest</i> two values be deleted
from this set:<br>
<br>
pwdFailureTime: 20150702184821Z<br>
pwdFailureTime: 20150702185821Z<br>
<br>
(To be more precise, I'll suggest that when ppolicy_bind_response()
processes the BIND failure that triggers the addition of
20150702191012Z to pwdFailureTime, that's when it could delete the
two oldest values. It already loops through the entire set of
pwdFailureTime values, so adding a check to delete older ones above
the pwdMaxFailure count could be done in that same loop).<br>
<br>
I'm not seeing how this would conflict with the password policy
specification -- am I missing something?<br>
<br>
In the particular situation that's prompting this request, it's not
just two or three values -- for one entry it was over 38000 values
that had accumulated over time! (and generally high values for many
other entries).<br>
<br>
ITS#7161 doesn't address this issue -- it adds more precision to the
timestamp values, but it doesn't purge excess stale values.<br>
<br>
Here's how this issue relates to ITS#7089. In ITS#7089, the
requester was seeing failed bind attempts to entries that didn't
have a password defined. As a result, pwdFailureTime values were
consistently being added to these entries. The common theme is that
there is no built-in way (to my knowledge) in OpenLDAP to protect
against pwdFailureTime values continually being added to entries
indefinitely.<br>
<br>
This enhancement would mitigate that problem by putting a cap on the
number of pwdFailureTime attributes that could ever accumulate on an
entry -- the pwdMaxFailure count. Just like administrators have
control over expiring old log files, they would get the ability to
ensure that pwdFailureTime values couldn't accumulate indefinitely.<br>
<br>
Please let me know what you think.<br>
<br>
Thanks,<br>
<br>
-Kartik<br>
<br>
<br>
Michael Stroeder wrote:<br>
>> This wording in the slapo-ppolicy man page sounds friendly
towards this<br>
>> interpretation: "Excess timestamps beyond those allowed by
pwdMaxFailure <br>
>> may also be purged."<br>
>><br>
>> Looking at the source code though, it doesn't seem that
pwdFailureTime<br>
>> values are actually removed unless a successful bind occurs
-- whereupon <br>
>> all values of course are removed.<br>
>><br>
>> I would like to request an enhancement to purge stale
pwdFailureTime<br>
>> values as mentioned above.<br>
><br>
> Nope. The number of pwdFailureTime is also used as failure
lockout<br>
> counter. Actually it was improved with ITS#7161.<br>
><br>
>> This would also largely mitigate the issue raised in
ITS#7089<br>
><br>
> I don't see the relation with ITS#7089.<br>
<br>
</body>
</html>
--------------060309030709060507050000--
7 years, 11 months
(ITS#8173)
by Adrian.Raemy@vtg.admin.ch
--_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Dear Howard,
below you will find the slapd.conf of the OpenLDAP Proxy and the slapd.conf=
of the OpenLDAP Master where you can see which overlays we are using.
The debug symbol core dump we will provide asap, we need first install the =
debug packages for that on one host.
OpenLDAP Proxy slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/sudo.schema
include /etc/openldap/schema/guacConfigGroup.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/openldap
moduleload back_ldap.la
moduleload auditlog
overlay auditlog
auditlog /var/lib/ldap/auditlog/ldap.auditlog
TLSCertificateFile /etc/openldap/ssl.crt/server.crt
TLSCertificateKeyFile /etc/openldap/ssl.key/server.key
TLSCACertificatePath /etc/openldap/ssl.crt/
TLSCipherSuite HIGH:MEDIUM:-SSLv2
TLSVerifyClient allow
security ssf=3D112 update_ssf=3D112 tls=3D56
loglevel stats none
sizelimit unlimited
database ldap
protocol-version 3
tls start
suffix "dc=3Dxxxx.xx"
uri "ldap://xxxx.xx.xxx.xx.xx:389/"
idassert-authzFrom "*"
idle-timeout 1500
idletimeout 2700
And here the OpenLDAP Master slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/sudo.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/openldap/modules
TLSCertificateFile /etc/openldap/ssl.crt/server.crt
TLSCertificateKeyFile /etc/openldap/ssl.key/server.key
TLSCACertificatePath /etc/openldap/ssl.crt/
TLSCipherSuite HIGH:MEDIUM:-SSLv2
TLSVerifyClient allow
security ssf=3D112 update_ssf=3D112 tls=3D56
password-hash {SHA}
loglevel stats sync none
include /etc/openldap/slapd.access
sizelimit unlimited
database hdb
readonly off
suffix "dc=3Dxxx.xx"
rootdn "cn=3DManager,dc=3Dxxx.xx"
rootpw {SSHA}xxxxxxxxxx
directory /var/lib/ldap/
checkpoint 1024 5
cachesize 100000
idlcachesize 100000
index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid eq
index uidNumber pres,eq
index gidNumber pres,eq
index uniqueMember pres,eq
index memberOf pres,eq
index sudoUser pres,eq,sub
index entryCSN,entryUUID eq
index mail pres,eq,sub
index userClass pres,eq
index ipHostNumber eq
overlay unique
unique_uri ldap:///?uid?sub
overlay ppolicy
ppolicy_default "cn=3Dxxxx,ou=3Dxxxxx,dc=3Dxxxx,dc=3Dxxxx.xx"
ppolicy_use_lockout
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
memberof-refint true
memberof-dn cn=3DMemberOfOverlay,dc=3Dxxx.xx
overlay auditlog
auditlog /var/lib/ldap/auditlog/ldap.auditlog
database monitor
best Regards
Adrian
--_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Dear Howard,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">below you will find the slapd.c=
onf of the OpenLDAP Proxy and the slapd.conf of the OpenLDAP Master where y=
ou can see which overlays we are using.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The debug symbol core dump we w=
ill provide asap, we need first install the debug packages for that on one =
host.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">OpenLDAP Proxy slapd.conf:<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/core.schema<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/cosine.schema<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/inetorgperson.schema<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/openldap.schema<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/rfc2307bis.schema<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/ppolicy.schema<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/sudo.schema<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/guacConfigGroup.schema<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">pidfile =
/var/run/slapd/slapd.pid<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">argsfile  =
; /var/run/slapd/slapd.args<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">modulepath /u=
sr/lib/openldap<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">moduleload ba=
ck_ldap.la<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">moduleload &nb=
sp; auditlog<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">overlay =
auditlog<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">auditlog  =
; /var/lib/ldap/auditlog/ldap.auditlog<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"FR-CH">TLSCertificateFile &=
nbsp; /etc/openldap/ssl.crt/server.crt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"FR-CH">TLSCertificateKeyFile /et=
c/openldap/ssl.key/server.key<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"FR-CH">TLSCACertificatePath  =
; /etc/openldap/ssl.crt/<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSCipherSuite  =
; HIGH:MEDIUM:-SSLv2<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSVerifyClient &nbs=
p; allow<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">security ssf=3D112 update_ssf=
=3D112 tls=3D56<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">loglevel  =
; stats none<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">sizelimit &nbs=
p; unlimited<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">database  =
; ldap<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">protocol-version &nb=
sp; 3<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">tls &nbs=
p; =
start<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">suffix &=
nbsp; "dc=3Dxxxx.xx&qu=
ot;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">uri &nbs=
p; =
"ldap://xxxx.xx.xxx.xx.xx:389/"<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idassert-authzFrom "=
*"<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idle-timeout &=
nbsp; 1500<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idletimeout &n=
bsp; 2700<o:p></o:p></span></p>
<div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w=
indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm">
<p class=3D"MsoNormal" style=3D"border:none;padding:0cm"><span lang=3D"EN-U=
S"><o:p> </o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">And here the OpenLDAP Master sl=
apd.conf<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/core.schema<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/cosine.schema<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/inetorgperson.schema<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/openldap.schema<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/rfc2307bis.schema<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/ppolicy.schema<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/schema/sudo.schema<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">pidfile  =
; /var/run/slapd/slapd.pid<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">argsfile  =
; /var/run/slapd/slapd.args<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">modulepath &nb=
sp; /usr/lib/openldap/modules<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSCertificateFile &=
nbsp; /etc/openldap/ssl.crt/server.crt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSCertificateKeyFile /et=
c/openldap/ssl.key/server.key<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSCACertificatePath  =
; /etc/openldap/ssl.crt/<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSCipherSuite  =
; HIGH:MEDIUM:-SSLv2<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">TLSVerifyClient &nbs=
p; allow<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">security ssf=3D112 update_ssf=
=3D112 tls=3D56<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">password-hash {SHA}<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">loglevel  =
; stats sync none<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">include =
/etc/openldap/slapd.access<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">sizelimit &nbs=
p; unlimited<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">database  =
; hdb<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">readonly  =
; off<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">suffix &=
nbsp; "dc=3Dxxx.xx"<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">rootdn &=
nbsp; "cn=3DManager,dc=3Dxxx.xx"<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">rootpw &=
nbsp; {SSHA}xxxxxxxxxx<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">directory &nbs=
p; /var/lib/ldap/<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">checkpoint &nb=
sp; 1024 5<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">cachesize &nbs=
p; 100000<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">idlcachesize &=
nbsp; 100000<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index objectClass &n=
bsp; eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index cn  =
; &n=
bsp; pres,sub,eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index sn  =
; &n=
bsp; pres,sub,eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index uid &nbs=
p; &=
nbsp; eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index uidNumber &nbs=
p; pres,eq<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index gidNumber &nbs=
p; pres,eq<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index uniqueMember &=
nbsp; pres,eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index memberOf  =
; pres,eq<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index sudoUser  =
; pres,eq,sub<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index entryCSN,entryUUID &=
nbsp; eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index mail &nb=
sp; =
pres,eq,sub<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index userClass &nbs=
p; pres,eq<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">index ipHostNumber &=
nbsp; eq<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">overlay unique<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">unique_uri ldap:///?uid?sub<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">overlay =
ppolicy<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">ppolicy_default &nbs=
p; "cn=3Dxxxx,ou=3Dxxxxx,dc=3Dxxxx,dc=3Dxxxx.xx"<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">ppolicy_use_lockout<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">overlay =
memberof<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">memberof-group-oc g=
roupOfUniqueNames<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">memberof-member-ad unique=
Member<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">memberof-refint &nbs=
p; true<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">memberof-dn &n=
bsp; cn=3DMemberOfOverlay,dc=3Dxxx.xx<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">overlay =
auditlog<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">auditlog  =
; /var/lib/ldap/auditlog/ldap.aud=
itlog<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">database  =
; monitor<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">best Regards<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Adrian<o:p></o:p></span></p>
</div>
</body>
</html>
--_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_--
7 years, 11 months
(ITS#8188) unable to see the users on client after importing the TLS certificate
by vijeshkrishna@yahoo.com
Full_Name: Vijesh
Version: 2.4
OS: RHEL 6.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (15.219.201.69)
Hello Team,
thank you for OpenLDAP.
i am condiguring a new LDAP server.
have updated all the mandatory details and added users to redhat and then
imported to LDAP.
i can see the user names in slapcat o/p. but unable to login or see via getent
passwd.
Could you help me on this instance please. much appreciate your help.
dn: uid=vijesh,ou=People,dc=autozone,dc=com
uid: vijesh
cn: vijesh
sn: vijesh
mail: vijesh(a)autozone.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQ2JGM0MzF4WmpqJDRHUGlpOWZOb2tOMGNyQzI1OW84YmRPREtKQkF
kSkt6ZFZaNXFUWWYwLjNHTVNyc2RnLy5OcVJ1M2s4UExOdC9TZ3FKTUl4WmxsdHk1V1FFaU0vUW4x
shadowLastChange: 16618
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 504
gidNumber: 504
homeDirectory: /home/vijesh
structuralObjectClass: inetOrgPerson
entryUUID: 1c742176-b525-1034-9cce-db949f9d492f
creatorsName: cn=Manager,dc=autozone,dc=com
createTimestamp: 20150702164245Z
entryCSN: 20150702164245.974424Z#000000#000#000000
modifiersName: cn=Manager,dc=autozone,dc=com
modifyTimestamp: 20150702164245Z
dn: cn=vijesh,ou=MC,dc=autozone,dc=com
objectClass: posixGroup
objectClass: top
cn: vijesh
userPassword:: e2NyeXB0fXg=
gidNumber: 504
structuralObjectClass: posixGroup
entryUUID: 2ae69360-b525-1034-9ccf-db949f9d492f
creatorsName: cn=Manager,dc=autozone,dc=com
createTimestamp: 20150702164310Z
entryCSN: 20150702164310.212553Z#000000#000#000000
modifiersName: cn=Manager,dc=autozone,dc=com
modifyTimestamp: 20150702164310Z
dn: dc=autozone,dc=com
dc: autozone
objectClass: top
objectClass: domain
objectClass: domainRelatedObject
associatedDomain: autozone.com
structuralObjectClass: domain
entryUUID: 26091f28-b3bf-1034-8106-b1690628f900
creatorsName: cn=Manager,dc=autozone,dc=com
createTimestamp: 20150630220022Z
entryCSN: 20150630220022.221149Z#000000#000#000000
modifiersName: cn=Manager,dc=autozone,dc=com
modifyTimestamp: 20150630220022Z
dn: ou=Hosts,dc=autozone,dc=com
ou: Hosts
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: autozone.com
structuralObjectClass: organizationalUnit
entryUUID: 2615b6ac-b3bf-1034-8107-b1690628f900
creatorsName: cn=Manager,dc=autozone,dc=com
createTimestamp: 20150630220022Z
entryCSN: 20150630220022.303673Z#000000#000#000000
modifiersName: cn=Manager,dc=autozone,dc=com
modifyTimestamp: 20150630220022Z
[root@DL380g5i2u34 /]# authconfig-tui
Starting sssd: [ OK ]
Stopping nslcd: [ OK ]
[root@DL380g5i2u34 /]# ps -ef |grep -i sssd
root 14849 1 0 00:51 ? 00:00:00 /usr/sbin/sssd -f -D
root 14851 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_be -d 0
--debug-to-files --domain default
root 14855 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_nss -d 0
--debug-to-files
root 14856 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_pam -d 0
--debug-to-files
root 14869 8260 0 00:51 pts/0 00:00:00 grep -i sssd
[root@DL380g5i2u34 /]# su - user1
su: user user1 does not exist
[root@DL380g5i2u34 /]# su - vijesh
su: user vijesh does not exist
[root@DL380g5i2u34 /]#
please let me know if you need any additional information?
thank you,
Vijesh
7 years, 11 months