389-users March 2012

389-users@lists.fedoraproject.org

45 participants
64 discussions

SASL and GSSAPI replication help - Error w/ Realm
by Matt Wells 15 Mar '12

15 Mar '12

I have a multi-master configuration of 389-directory server. I'm attempting to replicate w/ SASL/GSSAPI but It's not getting the realm. Note this replication is not with Windows AD. It's LDAP to LDAP The error I get is - [15/Mar/2012:10:48:30 -0700] set_krb5_creds - Could not get initial credentials for principal [ldap/server1@] in keytab [WRFILE:/etc/krb5.keytab]: -1765328164 (Cannot resolve network address for KDC in requested realm) [15/Mar/2012:10:48:30 -0700] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_99' not found)) [15/Mar/2012:10:48:30 -0700] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) In kerberos all principles are created and in the /etc/krb5.keytab the following exist; additionally the permissions have been set all the way to 777 to ensure a permissions issue is not in play. slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 2 host/server1(a)EXAMPLE.COM 2 2 host/server1(a)EXAMPLE.COM 3 2 host/server1(a)EXAMPLE.COM 4 2 host/server1(a)EXAMPLE.COM 5 2 host/server2(a)EXAMPLE.COM 6 2 host/server2(a)EXAMPLE.COM 7 2 host/server2(a)EXAMPLE.COM 8 2 host/server2(a)EXAMPLE.COM 9 3 ldap/server1(a)EXAMPLE.COM 10 3 ldap/server1(a)EXAMPLE.COM 11 3 ldap/server1(a)EXAMPLE.COM 12 3 ldap/server1(a)EXAMPLE.COM 13 3 ldap/server2(a)EXAMPLE.COM 14 3 ldap/server2(a)EXAMPLE.COM 15 3 ldap/server2(a)EXAMPLE.COM 16 3 ldap/server2(a)EXAMPLE.COM My question is the following - Shouldn't my first error from above read "[15/Mar/2012:10:48:30 -0700] set_krb5_creds - Could not get initial credentials for principal [ldap/server1(a)EXAMPLE.COM]" It makes sense to me that I am missing my realm, without that I of course couldn't get my tgt from the kdc. But where do I define that realm? I've looked in the cn=mapping,cn=sasl,cn=config but have not seen a realm to define. I've tested for fun changing these attributes but to no avail. nssaslmapbase dc=\2,dc=\3 mapregexstring \(.*\)(a)\(.*\)\.\(.*\) Any help would be greatly appreciated! Software Version - RHEL 6.1 --- 389-admin-1.1.25-1.el6.x86_64.rpm 389-admin-console-1.1.8-1.el6.noarch.rpm 389-adminutil-1.1.14-2.el6.x86_64.rpm 389-console-1.1.7-1.el6.noarch.rpm 389-ds-console-1.2.6-1.el6.noarch.rpm 389-dsgw-1.1.7-2.el6.x86_64.rpm

1 0

Req PPA link for Ubuntu
by s.varadha rajan 15 Mar '12

15 Mar '12

Hi Team, We are trying to install 389 ds server in Ubuntu 10.04 x86-64 edition. we followed the doc from the site " https://help.ubuntu.com/community/FedoraDirectoryServer" . In that site, they have specified the following url, deb http://ppa.launchpad.net/ubuntu-389-directory-server/ppa/ubuntu/ karmic maindeb-src http://ppa.launchpad.net/ubuntu-389-directory-server/ppa/ubuntu/ karmic main. Once if added the above Url in the Sources list, we can easily install 389 ds entire server in the Ubuntu server edition.but now a days this link may be down and there is no alternative links. i have searched in google but, no luck.Please let me know alternative link for the URL's or is there any other way we can install complete 389 ds server,fedors-idm-console,etc. Please help me on this Regards, Varad

3 6

About LDAP filters
by Juan Asensio Sánchez 14 Mar '12

14 Mar '12

Hi Is it important the order of the filter in a search? So, what's the most optomized filter? (&(uid=*)(objectClass=sambaSamAccount)) Or (&(objectClass=sambaSamAccount)(uid=*)) Or which is the best of these two: (&(uid=user)(ou:dn:=People)) Or (&(ou:dn:=People)(uid=user)) Regards and thanks in advance.

3 2

Troublesome Connection reset by peer errors
by Alther, Nicholas 14 Mar '12

14 Mar '12

I am seeking some assistance in isolating a re-occurring problem we are experiencing with our 389 DS Version 1.2.8.3 installation. We use the directory server for user authentication to our website. Every couple of days we start getting errors from our website login application reporting a user authentication timed out. These timeouts get more frequent as time passes. Our fix now is to restart the directory server which fixes the problem for a couple of days then the timeouts start happening again. I traced one application timeout back to the ds access logs and found the following entry at the same time: [14/Mar/2012:10:23:01 -0500] conn=14730 op=-1 fd=1093 closed error 104 (Connection reset by peer) - TCP connection reset by peer. I looked through the older logs and the only time this conn/fd was used was two days ago. Here are the access log entries: [12/Mar/2012:14:33:06 -0500] conn=14730 fd=1093 slot=1093 connection from 10.1.xx.xx to 10.1.xx.xx [12/Mar/2012:14:33:06 -0500] conn=14730 op=0 BIND dn="uid,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:33:06 -0500] conn=14730 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=theManager,dc=domain,dc=com" [12/Mar/2012:14:33:06 -0500] conn=14730 op=1 SRCH base="ou=users,ou=external,dc=domain,dc=com" scope=2 filter="(&(uid=xxxxx)(objectClass=inetUser))" attrs="1.1" [12/Mar/2012:14:33:06 -0500] conn=14730 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:33:06 -0500] conn=14730 op=2 BIND dn="uid=xxxxx,ou=users,ou=external,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:33:06 -0500] conn=14730 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=xxxxx,ou=users,ou=external,dc=domain,dc=com" [12/Mar/2012:14:33:06 -0500] conn=14730 op=3 BIND dn="uid,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:33:06 -0500] conn=14730 op=3 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=theManager,dc= domain,dc=com" [12/Mar/2012:14:35:20 -0500] conn=14730 op=4 SRCH base="ou=groups,ou=external,dc= domain,dc=com" scope=2 filter="(&(cn=domain)(|(objectClass=groupOfURLs)(objectClass=groupOfNames)))" attrs="1.1" [12/Mar/2012:14:35:20 -0500] conn=14730 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:35:20 -0500] conn=14730 op=5 SRCH base="ou=groups,ou=external,dc= domain,dc=com" scope=2 filter="(&(member=cn=domain,ou=groups,ou=external,dc=domain,dc=com)(objectClass=groupOfNames))" attrs="cn" [12/Mar/2012:14:35:20 -0500] conn=14730 op=5 RESULT err=0 tag=101 nentries=0 etime=0 [12/Mar/2012:14:36:50 -0500] conn=14730 op=6 SRCH base="ou=users,ou=external,dc=domain,dc=com" scope=2 filter="(&(uid=xxxxxx)(objectClass=inetUser))" attrs="1.1" [12/Mar/2012:14:36:50 -0500] conn=14730 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:36:50 -0500] conn=14730 op=7 BIND dn="uid=xxxxxx,ou=users,ou=external,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:36:50 -0500] conn=14730 op=7 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=xxxxxx,ou=users,ou=external,dc=domain,dc=com" [12/Mar/2012:14:36:50 -0500] conn=14730 op=8 BIND dn="uid=theManager,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:36:50 -0500] conn=14730 op=8 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=theManager,dc=domain,dc=com" [12/Mar/2012:14:37:02 -0500] conn=14730 op=9 SRCH base="ou=groups,ou=external,dc=domain,dc=com" scope=2 filter="(&(cn=domain)(|(objectClass=groupOfURLs)(objectClass=groupOfNames)))" attrs="1.1" [12/Mar/2012:14:37:02 -0500] conn=14730 op=9 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:37:02 -0500] conn=14730 op=10 SRCH base="ou=groups,ou=external,dc=domain,dc=com" scope=2 filter="(&(member=cn=domain,ou=groups,ou=external,dc=domain,dc=com)(objectClass=groupOfNames))" attrs="cn" [12/Mar/2012:14:37:02 -0500] conn=14730 op=10 RESULT err=0 tag=101 nentries=0 etime=0 [12/Mar/2012:14:39:35 -0500] conn=14730 op=11 SRCH base="ou=users,ou=external,dc=domain,dc=com" scope=2 filter="(&(uid=xxxxxx)(objectClass=inetUser))" attrs="1.1" [12/Mar/2012:14:39:35 -0500] conn=14730 op=11 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:39:35 -0500] conn=14730 op=12 BIND dn="uid=xxxxxx,ou=users,ou=external,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:39:35 -0500] conn=14730 op=12 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=xxxxxx,ou=users,ou=external,dc=domain,dc=com" [12/Mar/2012:14:39:35 -0500] conn=14730 op=13 BIND dn="uid=theManager,dc=domain,dc=com" method=128 version=3 [12/Mar/2012:14:39:35 -0500] conn=14730 op=13 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=theManager,dc=domain,dc=com" [12/Mar/2012:14:40:23 -0500] conn=14730 op=14 SRCH base="ou=groups,ou=external,dc=domain,dc=com" scope=2 filter="(&(cn=domain)(|(objectClass=groupOfURLs)(objectClass=groupOfNames)))" attrs="1.1" [12/Mar/2012:14:40:23 -0500] conn=14730 op=14 RESULT err=0 tag=101 nentries=1 etime=0 [12/Mar/2012:14:40:23 -0500] conn=14730 op=15 SRCH base="ou=groups,ou=external,dc=domain,dc=com" scope=2 filter="(&(member=cn=domain,ou=groups,ou=external,dc=domain,dc=com)(objectClass=groupOfNames))" attrs="cn" [12/Mar/2012:14:40:23 -0500] conn=14730 op=15 RESULT err=0 tag=101 nentries=0 etime=0 The scenario seems to be that the DS works fine after a restart until it runs out of unused connections and/or file descriptors (max FDs= 8192). When it starts recycling connections and/or file descriptors the 104 errors start appearing more often in the access logs and we start getting more authentication errors. We suspect that the original connection never got terminated correctly but don't know if it is the application that is at fault or a DS setting. Our servers have been tuned according to the wiki doc at http://directory.fedoraproject.org/wiki/Performance_Tuning#Linux We have set our idle "timeout" to 60 seconds and search "timelimit" to 120 seconds with no change in behavior. Watching netstat -nap | grep slapd shows established connections that do not drop off, just continually grow. Any help would be greatly appreciated. Nicholas J Alther Sr. Software Developer/Analyst Black Hills Corporation Phone: 605.721.2158 Cell: 605.593.1899 Nicholas J Alther Sr. Software Developer/Analyst Phone: 605.721.2158 Cell: 605.593.1899 ________________________________ This electronic message transmission contains information from Black Hills Corporation, its affiliate or subsidiary, which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware the disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic transmission in error, please reply to sender immediately; then delete this message without copying it or further reading.

2 1

bypassing limits for persistent search and specific user
by Petr Spacek 14 Mar '12

14 Mar '12

Hello list, I'm looking for way how to bypass nsslapd-sizelimit and nsslapd-timelimit for persistent search made by specific user (or anything made by that user). Please, can you point me to right place in documentation about persistent search/user specific settings in 389? I googled for a while, but I can't find exact way how to accomplish this. I found attributes nsSizeLimit and nsTimeLimit in http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/… , but I'm not sure how to deploy them. If bypassing is not possible in 389: Is there any way how to enumerate all records from given subtree part-by-part? (My guess: VLV or something similar.) I know only basics about persistent search and next to nothing about VLV, so sorry if I'm completely wrong. --- Background / why I needed this / long story --- FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS records from LDAP database and populates BIND's internal memory with them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/) This plugin can use persistent search, which enables reflecting changes in LDAP inside BIND immediately. At this moment, plugin after start do persistent search for all DNS records. This single query can lead to tens of thousands records - and of course fails, because nssldapd-sizelimit stops that. Another problem arises with databases smaller than sizelimit - query is ended after timelimit and has to be re-established. It leads to periodical re-downloading whole DNS DB. Question is: It's possible to bypass limits for this connection/user OR plugin is completely broken by design? Thanks for you time. Petr^2 Spacek @ Red Hat @ Brno office

3 5

Announcing 389 Directory Server version 1.2.10.4 Testing
by Rich Megginson 14 Mar '12

14 Mar '12

The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.4. This release contains a fix for a bug that causes the directory server to hang when using compare operations with virtual attributes. No new features were added after alpha 8, just many bug fixes. There are also 389-adminutil, 389-admin, and 389-dsgw packages in Testing. NEW: EL6 support Beginning with RHEL 6.2, the 389-ds-base package is included in the base OS. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions. However, the 389 Project will still make the full 389-ds-base package available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information. NEW: Issue Tracking System We have moved our ticket tracking system from the Red Hat Bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora Hosted Trac https://fedorahosted.org/389. All of the old 389 bugs have been copied to Trac. All new bugs, feature requests, and tasks should be entered in Trac This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 In addition to the tickets for Milestone 1.2.10.3 there were a couple of issues found by valgrind that have been fixed. NEW: Plugin Authors WARNING: Plugins should be made transaction aware so that they can be called from within a backend pre/post transaction plugin. Otherwise, attempting to perform an internal operation will cause a deadlock. See http://directory.fedoraproject.org/wiki/Plugins Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil # or for EPEL yum upgrade --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. * Go to https://admin.fedoraproject.org/updates * In the Search box in the upper right hand corner, type in the name of the package * In the list, find the version and release you are using (if you're not sure, use rpm -qi <package name> on your system) and click on the release * On the page for the update, scroll down to "Add a comment" and provide your input Or just send us an email to 389-users(a)lists.fedoraproject.org Reporting Issues https://fedorahosted.org/389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download

3 3

LDAP server is unwilling to perform
by mjames＠guesswho.com 13 Mar '12

13 Mar '12

Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the "Typical" setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs. At this point, I can't establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with "LDAP server is unwilling to perform". In the error log, I see one error. Any help is appreciated. Thanks, Mike [12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement "cn=389 to analog-01v,cn=replica,cn=dc\3d<MY_DOMAIN>\2c dc\3dcom,cn=mapping tree,cn=config" Existing server: RHEL 5.7 32-bit [root@x-web-389-01 ~]# rpm -qa | grep 389 389-admin-console-1.1.8-1.el5 389-ds-base-libs-1.2.9.9-1.el5 389-ds-console-doc-1.2.6-1.el5 389-adminutil-1.1.14-1.el5 389-dsgw-1.1.7-2.el5 389-ds-console-1.2.6-1.el5 389-console-1.1.7-3.el5 389-admin-1.1.23-1.el5 389-admin-console-doc-1.1.8-1.el5 389-ds-base-1.2.9.9-1.el5 389-ds-1.2.1-1.el5 New server: CentOS 6.2 [root@x-analog-01v ~]# rpm -qa | grep 389 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-libs-1.2.10.3-1.el6.x86_64 389-ds-1.2.2-1.el6.noarch 389-console-1.1.7-1.el6.noarch 389-admin-console-1.1.8-1.el6.noarch 389-dsgw-1.1.7-2.el6.x86_64 389-adminutil-1.1.14-2.el6.x86_64 389-admin-1.1.25-1.el6.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-base-1.2.10.3-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch

3 10

Re: [389-users] New Zenoss ZenPack to monitor 389 (and other, cn=monitor) DS
by Alan Milligan 13 Mar '12

13 Mar '12

Juan Carlos wrote: > Hi, thanks for the pack. > On ZenOSS3.2.1 I get the message " 'NoneType' object has no attribute 'clone'" when I try to install it. That's a bit of a pain. But we don't really trust Zenoss to release anything around Zope and use a much more modern Zope stack (including quite a few patches to get Zenoss to behave properly). I suspect your error is due to Zenoss's version of ZODB - but you've not exactly given us a stack trace ... Alan

1 0

New Zenoss ZenPack to monitor 389 (and other cn=monitor) DS
by Alan Milligan 13 Mar '12

13 Mar '12

Hi, I recently released ZenPacks.lbn.LDAPMonitor for large-scale DS installations. It's available on PyPi: http://pypi.python.org/pypi/ZenPacks.lbn.LDAPMonitor/3.0.3 We do enterprise LDAP at: http://linux.last-bastion.net/LBN/up2date/aim/13 We do enterprise Zenoss monitoring at: http://linux.last-bastion.net/LBN/monitor/aim/13 These RPM packages also run on RHEL6/CentOS6, and you can find our BastionLinux on AWS/EC2, and we do make the systems available on VMWare/vSphere (and other virtualisation) platforms. Please do feel free to download and use the ZenPack. If you're using other cn=monitor LDAP's, please do let us know and we'll try and ensure compatibility with our RRD graphs. Alan

2 1

CMP operations against pwdPolicySubentry hanging
by Iain Morgan 12 Mar '12

12 Mar '12

Hello, On a fairly frequent basis, one of my 389 DS servers hangs after certain CMP operations. Once this happens, the server cannot be shutdown gracefully. This has been going on for several weeks, and I have not yet found a solution. My setup consists of two systems running RHEL 6.2 with 389 DS 1.2.9.16. Multimaster replication is enabled between the two servers, but the client systems (currently just two test systems) preferrentially use the same server, ServerA. The second server, ServerB, is the one which is experiencing the problem. We are using class-of-service entries to to set the values for the shadowMax, shadowMin, and shadowWarning attributes. And we are conditionally setting a pwdPolicySubentry attribute for some entries in the same manner. If I execute an ldapcompare command, such as the following: # ldapcompare uid=imorgan,ou=People,dc=example,dc=com \ pwdpolicysubentry:"cn=Special Policy,ou=Policies,dc=example,dc=com" the command will occassionally hang. Most of the time, the command succeeds and indicates that the attribute is not defined for that entry. However, once or twice a day it will simply hang. The access log shows that the CMP request was received, but no result is logged. After this occurs, the server will not shut down gracefully. The init script fails to shut down the server and I end up having to send a SIGKILL to ns-slapd. The error log does not report any issues. CMP operations against other attributes, such as loginShell, do not seem to exhibit this problem. Also, the problem does not occur on ServerA; only on ServerB. Once the CMP operation has hung, comparisons against other attributes, even shadowMax, continue to work. As noted above, most of the time the CMP operation returns normally. However, if I reinitialize ServerB from ServerA, the problem occurs with the first CMP operation against ServerB. Both servers have the same set of RPMs and the dse.ldif on both systems do not have any significant differences. Has anyone seen a similar issue? Any suggestions on how to debug of fix this? A somewhat simplified and redacted version of the class-of-service configuration is listed below. Thanks -- Iain Morgan dn: cn=Account Templates,ou=People,dc=example,dc=com objectClass: top objectClass: nsContainer cn: Account Templates dn: cn="cn=User Account,ou=People,dc=example,dc=com", cn=Account Templates,ou=People,dc=example,dc=com objectClass: top objectClass: ldapSubEntry objectClass: extensibleObject objectClass: cosTemplate cn: cn=User Account,ou=People,dc=example,dc=com cosPriority: 10 shadowMin: 1 shadowMax: 60 shadowWarning: 7 dn: cn=User Account CoS,ou=People,dc=example,dc=com objectClass: top objectClass: ldapSubentry objectClass: cosSuperDefinition objectClass: cosPointerDefinition cn: User Account CoS cosTemplateDN: cn="cn=User Account,ou=People,dc=example,dc=com", cn=Account Templates,ou=People,dc=example,dc=com cosAttribute: shadowMin default cosAttribute: shadowMax default cosAttribute: shadowWarning default dn: cn="cn=Special Account,ou=People,dc=example,dc=com", cn=Account Templates,ou=People,dc=example,dc=com objectClass: top objectClass: ldapSubEntry objectClass: extensibleObject objectClass: cosTemplate cn: cn=Special Account,ou=People,dc=example,dc=com cosPriority: 5 pwdPolicySubentry: cn=Special Policy,ou=Policies,dc=example,dc=com shadowMin: 1 shadowMax: 60 shadowWarning: 7 dn: cn=Special Account,ou=People,dc=example,dc=com objectClass: top objectClass: ldapSubentry objectClass: nsRoleDefinition objectClass: nsComplexRoleDefinition objectClass: nsFilteredRoleDefinition cn: Special Account nsRoleFilter: (&(objectClass=shadowAccount)(gidNumber=1000)) dn: cn=Account CoS,ou=People,dc=example,dc=com objectClass: top objectClass: ldapSubentry objectClass: cosSuperDefinition objectClass: cosClassicDefinition cn: Account CoS cosTemplateDN: cn=Account Templates,ou=People,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry default operational cosAttribute: shadowMin default cosAttribute: shadowMax default cosAttribute: shadowWarning default -- Iain Morgan

2 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2012