SASL and GSSAPI replication help - Error w/ Realm
by Matt Wells
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
12 years, 1 month
About LDAP filters
by Juan Asensio Sánchez
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.
12 years, 1 month
Troublesome Connection reset by peer errors
by Alther, Nicholas
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.
12 years, 1 month
bypassing limits for persistent search and specific user
by Petr Spacek
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-singl...
, 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
12 years, 1 month
Announcing 389 Directory Server version 1.2.10.4 Testing
by Rich Megginson
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
12 years, 1 month
LDAP server is unwilling to perform
by mjames@guesswho.com
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
12 years, 1 month
Re: [389-users] New Zenoss ZenPack to monitor 389 (and other, cn=monitor) DS
by Alan Milligan
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
12 years, 1 month
CMP operations against pwdPolicySubentry hanging
by Iain Morgan
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
12 years, 1 month