openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

LMDB ITS 8324 WriteMap performance on Windows
by Victor Baybekov 05 Jan '16

05 Jan '16

Hi, Thanks a lot for ITS#8324! For embedded, not server, use case that change adds much convenience. I have tested the master from .NET via P/Invoke and do not see any major slowdown with default options. To insert 10M <int32,int32> pairs inside a single transaction v.0.9.14 takes minimum 3400 msec, latest master takes minimum 3750 msec. This is not scientific, just best result from 10 runs. Sometimes both timings increase to 5000+ msecs. On average slowdown is visible but tolerable - from 2.9 Mops to 2.6 Mops (absolute numbers are still awesome!). With Append and NoSync I could get 3.45 Mops on the same test with master build. However, with WriteMap performance of master drops 3x to 10000 msec or just 1 Mops, while for the v.0.9.14 performance with WriteMap improves to 2350 msec or 4.25 Mops. Is this the cost of convenience or it could be fixed so that WriteMap still "is faster and uses fewer mallocs" as the docs say? Best regards, Victor

3 5

2.4.43 "make test" hanging in "test039-glue-ldap-concurrency" on Solaris 10
by Greg Earle 05 Jan '16

05 Jan '16

Forgive me if this is the wrong place (maybe openldap-build?). I've built OpenLDAP 2.4.43 on Solaris 10 1/13 OK, but when I run the "make test" phase it hangs in the "test039-glue-ldap-concurrency" test: -- >>>>> Starting test039-glue-ldap-concurrency for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... MONITORDB yes SRCDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun/./testdata DSTDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun pwd /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests Using tester for concurrent server access... PID=16664 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". [... blah blah etc. ...] PID=17066 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17080 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17096 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". slapd-bind PID=17066: ldap_sasl_bind_s: Invalid credentials (49) PID=17102 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17112 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17118 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=17135 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=17135 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. -- This is the last output I get. "ps" shows several test servers running as well as the test harness clients; "lsof" shows the clients stuck in poll() and doing nothing. They all have ESTABLISHED connections to their servers. -- zorro:1:1014 [/] # truss -p 17118 pollsys(0x0002CEFC, 1, 0x00000000, 0x00000000) (sleeping...) ^C zorro:1:1015 [/] # truss -p 17135 pollsys(0x0002C39C, 1, 0x00000000, 0x00000000) (sleeping...) -- I did a "gcore" and it says it's waiting in ldap_int_select(): -- (dbx) where [1] __pollsys(0x2c39c, 0x1, 0x0, 0x0, 0xfef523f0, 0x0), at 0xfeede7ac [2] _pollsys(0x2c39c, 0x1, 0x0, 0x0, 0x0, 0x2bb00), at 0xfeece490 [3] _poll(0x2c39c, 0x1, 0xffffffff, 0xffbfed8c, 0xff3ec2cc, 0x0), at 0xfee74ccc =>[4] ldap_int_select(ld = 0x289d0, timeout = (nil)), line 1139 in "os-ip.c" [5] wait4msg(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 312 in "result.c" [6] ldap_result(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 117 in "result.c" [7] ldap_sasl_bind_s(ld = 0x289d0, dn = 0x2ba58 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US", mechanism = (nil), cred = 0xffbff080, sctrls = (nil), cctrls = (nil), servercredp = (nil)), line 210 in "sasl.c" -- Why are these things just sitting here instead of completing and exiting? BTW I am using the Solaris robust mutex fix patch (it wouldn't build otherwise) posted a few weeks back. Configured via ./configure --prefix=/opt/openldap --enable-modules --with-ldap-module=dynamic\ --enable-bdb --enable-rlookups --enable-wrappers --enable-dynamic \ --enable-ldap --disable-ipv6 --enable-overlays --with-threads --enable-relay\ --enable-syslog Puzzled in Pasadena, - Greg P.S. Here's the "ps" output if it matters zorro:1:1011 [/] # ps -ax PID TT S TIME COMMAND [...] 4413 pts/5 S 0:00 make test 4414 pts/5 S 0:00 sh -ce cd tests; make test 4415 pts/5 S 0:00 make test 4416 pts/5 S 0:00 make bdb 4418 pts/5 S 0:00 /bin/sh ./run -b bdb all 4429 pts/5 S 0:00 /bin/sh ./scripts/all 13917 pts/5 S 0:00 -sh 13922 pts/5 S 0:00 -csh 16491 pts/5 S 0:00 /bin/sh ./scripts/test039-glue-ldap-concurrency 16502 pts/5 S 0:44 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16560 pts/5 S 0:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16604 pts/5 S 2:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16649 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-tester -P ./progs -d /usr/local/src/network 16668 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16674 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16677 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16680 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16943 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16957 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modify -h localhost -p 9013 -D cn=Man 16959 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-addel -h localhost -p 9013 -D cn=Mana 16981 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17005 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17017 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17033 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17047 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17061 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17066 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17080 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17096 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17102 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17112 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17118 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17135 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L

1 0

Re: pass-through authentication
by Dan White 04 Jan '16

04 Jan '16

On 12/17/15 18:32 -0600, Timothy Keith wrote: >We are attempting to set up an LDAP server which will answer queries >from an application. The database will contain metadata on a set of >users in the application. The application will also query the server >to authenticate the user’s password, however, this server will not >house the password. That resides on another server, which our server >will query. We do not have administrative rights to the other >server. > > The difficulty we are having now is setting up the pass-through >authentication for the passwords. Any pointers in how to proceed with >this would be greatly appreciated. On 12/21/15 17:24 -0600, Timothy Keith wrote: >We have limited access to the servers. Same company, different IT >organization. Our LDAP requirement must be transparent to those servers. >We want to inherit the LDAP directory information from the Unix servers - >mostly the user Id and passwords, and add information that is needed by >applications that our servers will manage. On 12/31/15 09:51 -0600, Timothy Keith wrote: > On Wed, Dec 30, 2015 at 7:04 PM, Dan White <dwhite(a)cafedemocracy.org> wrote: >> On 12/30/15 18:51 -0600, Timothy Keith wrote: >> >>> This is tail of the latest saslauthd debug output : >>> >>> ldap_sasl_interactive_bind: user selected: DIGEST-MD5 >>> >> >> res_errno: 7, res_error: <SASL(-4): no mechanism available: >, res_matched: >>> <> >>> ldap_free_request (origid 1, msgid 1) >>> ldap_int_sasl_bind: DIGEST-MD5 >>> ldap_parse_sasl_bind_result >>> ldap_parse_result >>> ldap_msgfree >>> ldap_err2string >>> >> >> Is DIGEST-MD5 available on your ldap server? Try: >> >> ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" >> supportedSASLMechanisms >> Which should list the advertised sasl mechanisms. >> >> Verify the digest-md5 mechanism is installed with >> saslpluginviewer/pluginviewer. > >Dan, that ldapsearch returns : >dn: >supportedSASLMechanisms: PLAIN The server is only offering the PLAIN mechanism to you. It appears you're using saslauthd's ldap backend, and have explicitly configured 'ldap_mech: digest-md5' in your corresponding config. If that's correct, you could change that to PLAIN instead. Consider protecting the bind with tls if available. slapo-pbind may be a simpler alternative (to pass-through sasl authentication), depending on the specifics of your setup. -- Dan White

3 8

Re: openldap 2.4.43 keeps crashing
by Jephte Clain 04 Jan '16

04 Jan '16

2015-12-30 22:51 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, December 30, 2015 10:36 PM +0400 Jephte Clain > <jephte.clain(a)univ-reunion.fr> wrote: > >> 2015-12-29 20:47 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: >>> >>> --On Monday, December 28, 2015 10:18 PM -0800 Quanah Gibson-Mount >>> <quanah(a)zimbra.com> wrote: >>> >>>> David, >>>> >>>> Why haven't you reported this to the ITS? >>> >>> >>> >>> Discussed with Howard. It isn't in 0.9 yet because it hasn't been >>> confirmed if the fix is good or not. David, if that fix has resolved >>> the issue, *please* follow up with the ITS noting that to be the case. >>> >> >> Hello, >> >> I can confirm this is the problem I have. Starting slapd in debug >> mode, it dies after some time: >> >> /tmp/buildd/openldap-2.4.43/servers/slapd/back-mdb/../../../libraries/lib >> lmdb/mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in >> mdb_page_search_root() >> /usr/local/slaptools/lib/functions: line 44: 30232 Abandon >> /usr/sbin/slapd -h "$SLAPD_SERVICES" -g "$SLAPD_GROUP" -u >> "$SLAPD_USER" -F "$SLAPDD" -d "$dlevel" "$@" >> >> I didn't notice it because it doesn't dump core. And somehow, the >> initscript I use eats the stderr output of slapd (I'll fix it for >> future errors) >> >> For now, I'll revert to the previous working version, but I'm willing >> to test any fix >> The funny part is only the replica dies regularly, not the master >> although it is the one to receive the writes > > > You can apply the patch that was made to mdb.master to the 2.4.43 source > tree, and see if it resolves the problem or not. ;) Hmmm... I really need some holidays... I couldn't manage to find the commit today (too tired?) and now I remember grep is my friend $ git checkout mdb.master $ git log --pretty=oneline | grep 8336 58d1fd4c73c96ef3097816e975b3d421ead4d86e ITS#8336 fix page_search_root assert on FreeDB I'll have a look tomorrow. Thanks. Regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

2 2

Re: users don't get prompt to change password (pwdMustChange attribute)
by Rajagopal Rc 01 Jan '16

01 Jan '16

Hi All, Can any one help me on this please Thanks From: Rajagopal Rc/BLR/TCS To: openldap-technical(a)openldap.org Date: 12/24/2015 12:07 PM Subject: users don't get prompt to change password (pwdMustChange attribute) Hello, I am trying to force user to change their password at first logon and on password reset. OS RHEL7 Openldap version 2.4.39-7.el7_1.x86_64 I have tried the following 1) I have set the pwdMustChange attribute to TRUE in ppolicy, but when user logon to client at first time or after resetting password, it just allow suer to logon without prompting to change the password, 2) I have set the pwdReset attribute to TRUE in user attribute for particular user, this doesn't allow user to login at all and keep prompting for password without allowing to login. Also i red in blogs this is not correct way, but couldn't find more information on this. is there any way to force users to change their password at first logon and after resetting password by admin. ? Current ppolicy Thanks & Regards Raj =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0

LDAP ACL for restricting applications with same user dn
by Geo P.C. 01 Jan '16

01 Jan '16

Currently we need to configure Group based LDAP login for our custom applications. We have applications named app1, app2 etc. For restricting users to login for a particular application for eg app1 then for that user it should have attribute named *allowedService = app1*, for login to app2 that user need *allowedService = app2* So in that way we created users. Now for binding applications to ldap we created users like *cn=app1,ou=Applications,dc=prime,dc=ds,dc=geo,dc=com cn=app2,ou=Applications,dc=prime,dc=ds,dc=geo,dc=com* Now we configured LDAP ACL as follows: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" > filter="(allowedService=app1)" by > dn.exact="cn=app1,ou=Applications,dc=prime,dc=ds,dc=geo,dc=com" read by * > break > olcAccess: {3}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" > filter="(allowedService=app2)" by > dn.exact="cn=app2,ou=Applications,dc=prime,dc=ds,dc=geo,dc=com" read by * > break > olcAccess: {4}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" > attrs="entry" by dn.sub="ou=Applications,dc=prime,dc=ds,dc=geo,dc=com" read > by dn="cn=admin,dc=ds,dc=geo,dc=com" write by self read by * break > olcAccess: {5}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" > by dn.exact="cn=app3,ou=Applications,dc=prime,dc=ds,dc=geo,dc=com" read by > users read > olcAccess: {6}to dn.subtree="dc=prime,dc=ds,dc=geo,dc=com" by > anonymous write > But when any application that doesn't support filter (Like suiteCRM) we created rule *olcAccess: {5}* and bind it with *app3* user but then the whole ACL is not working and all users can login to all application. So can anyone please help us on it Thanks Geo

1 1

Re: pass-through authentication
by Timothy Keith 31 Dec '15

31 Dec '15

ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" supportedSASLMechanisms That ldapsearch returns : dn: supportedSASLMechanisms: PLAIN I tried this as well : ldapsearch -h localhost -Y digest-md5 -U my_userid -w my_password -v '(objectClass=*)' ldap_initialize( ldap://localhost ) SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: Tim On Thu, Dec 31, 2015 at 9:51 AM, Timothy Keith <timothy.g.keith(a)gmail.com> wrote: > Dan, that ldapsearch returns : > dn: > supportedSASLMechanisms: PLAIN > > On Wed, Dec 30, 2015 at 7:04 PM, Dan White <dwhite(a)cafedemocracy.org> > wrote: > >> On 12/30/15 18:51 -0600, Timothy Keith wrote: >> >>> This is tail of the latest saslauthd debug output : >>> >>> ldap_sasl_interactive_bind: user selected: DIGEST-MD5 >>> >> >> res_errno: 7, res_error: <SASL(-4): no mechanism available: >, >>> res_matched: >>> <> >>> ldap_free_request (origid 1, msgid 1) >>> ldap_int_sasl_bind: DIGEST-MD5 >>> ldap_parse_sasl_bind_result >>> ldap_parse_result >>> ldap_msgfree >>> ldap_err2string >>> >> >> Is DIGEST-MD5 available on your ldap server? Try: >> >> ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" >> supportedSASLMechanisms >> Which should list the advertised sasl mechanisms. >> >> Verify the digest-md5 mechanism is installed with >> saslpluginviewer/pluginviewer. >> >> -- >> Dan White >> > >

1 0

Re: pass-through authentication
by Timothy Keith 31 Dec '15

31 Dec '15

I'm still having troubles with pass-through SASL on RHEL testsaslauthd produces this message : 0: NO "authentication failed" With this in the system log : saslauthd logs reason=Unknown When saslauthd is launched in verbose mode and followed by testsaslauthd it prints : connect() : No such file or directory Tim On Thu, Dec 24, 2015 at 1:46 PM, Timothy Keith <timothy.g.keith(a)gmail.com> wrote: > As per my ongoing LDAP SASL design question, can anyone recommend a good > tutorial for pass-through authentication ? > > Tim > > On Tue, Dec 22, 2015 at 2:47 PM, Timothy Keith <timothy.g.keith(a)gmail.com> > wrote: > >> Uwe, your assistance could be very helpful. I followed Open LDAP >> tutorials but could not determine why the SASL requests fail. I am a >> newcomer to LDAP. >> >> Tim >> >> On Mon, Dec 21, 2015 at 12:04 PM, Hering, Uwe <uwe.hering(a)cgi.com> wrote: >> >>> Hello Tim, >>> >>> we have set up such a setup where one can authenticate against OpenLDAP >>> which redirects the request via saslauthd/kerberos to an AD server. Within >>> the AD a service account with corresponding keytab will be necessary. >>> >>> If you are interested I can try to get the pieces of information >>> together again. >>> >>> Regards, >>> >>> Uwe >>> >>> -----Ursprüngliche Nachricht----- >>> Von: openldap-technical [mailto:openldap-technical-bounces@openldap.org] >>> Im Auftrag von Timothy Keith >>> Gesendet: Freitag, 18. Dezember 2015 01:33 >>> An: openldap-technical(a)openldap.org >>> Betreff: pass-through authentication >>> >>> We are attempting to set up an LDAP server which will answer queries >>> from an application. The database will contain metadata on a set of users >>> in the application. The application will also query the server to >>> authenticate the user’s password, however, this server will not house the >>> password. That resides on another server, which our server >>> will query. We do not have administrative rights to the other >>> server. >>> >>> The difficulty we are having now is setting up the pass-through >>> authentication for the passwords. Any pointers in how to proceed with this >>> would be greatly appreciated. >>> >>> Regards, >>> >>> Tim >>> >>> >> >

2 3

Re: openldap 2.4.43 keeps crashing
by Jephte Clain 30 Dec '15

30 Dec '15

2015-12-29 20:47 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Monday, December 28, 2015 10:18 PM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> David, >> >> Why haven't you reported this to the ITS? > > > Discussed with Howard. It isn't in 0.9 yet because it hasn't been confirmed > if the fix is good or not. David, if that fix has resolved the issue, > *please* follow up with the ITS noting that to be the case. > Hello, I can confirm this is the problem I have. Starting slapd in debug mode, it dies after some time: /tmp/buildd/openldap-2.4.43/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() /usr/local/slaptools/lib/functions: line 44: 30232 Abandon /usr/sbin/slapd -h "$SLAPD_SERVICES" -g "$SLAPD_GROUP" -u "$SLAPD_USER" -F "$SLAPDD" -d "$dlevel" "$@" I didn't notice it because it doesn't dump core. And somehow, the initscript I use eats the stderr output of slapd (I'll fix it for future errors) For now, I'll revert to the previous working version, but I'm willing to test any fix The funny part is only the replica dies regularly, not the master although it is the one to receive the writes Thanks to all for your precious help. Very best regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

2 1

SASL Passthrough no request
by Küchler, Simon 30 Dec '15

30 Dec '15

Hello, I need help with the following problem. Our password authetication should use SASL but we don't see any requests in our Logs or by tcpdump. The password authentication should work as follows - userPassword-Attribute: {SASL}User@Domain - saslauthd -> use PAM - PAM -> use kerberos - kerberos -> send request to Active-Directory Server RPM list: --------------------- lshxx0693:~ # rpm -qa | grep sasl cyrus-sasl-gssapi-32bit-2.1.22-182.20.1 cyrus-sasl-gssapi-2.1.22-182.20.1 cyrus-sasl-2.1.22-182.20.1 cyrus-sasl-32bit-2.1.22-182.20.1 cyrus-sasl-digestmd5-2.1.22-182.20.1 cyrus-sasl-digestmd5-32bit-2.1.22-182.20.1 cyrus-sasl-devel-2.1.22-182.20.1 cyrus-sasl-saslauthd-2.1.22-182.19 lshxx0693:~ # rpm -qa | grep krb krb5-1.6.3-133.49.64.1 krb5-32bit-1.6.3-133.49.64.1 pam_krb5-2.3.1-47.12.1 pam_krb5-32bit-2.3.1-47.12.1 krb5-doc-1.6.3-133.49.64.1 krb5-plugin-kdb-ldap-1.6.3-133.49.64.1 krb5-server-1.6.3-133.49.64.1 krb5-client-1.6.3-133.49.64.1 lshxx0693:~ # rpm -qa | grep ldap openldap2-2.4.26-0.28.5 openldap2-client-2.4.26-0.28.5 openldap2-devel-2.4.26-0.28.5 pam_ldap-184-147.20 pam_ldap-32bit-184-147.20 nss_ldap-262-11.32.39.1 nss_ldap-32bit-262-11.32.39.1 libldap-2_4-2-2.4.26-0.28.5 libldap-2_4-2-32bit-2.4.26-0.28.5 libldapcpp1-0.3.0-0.9.29 libevoldap-2_4-2-2.4.12-4.19 yast2-ldap-2.17.8-0.7.61 yast2-ldap-client-2.17.38-0.7.2 yast2-ldap-server-2.17.44-0.5.1 lshxx0693:~ # rpm -qa | grep cyrus cyrus-sasl-gssapi-2.1.22-182.20.1 cyrus-sasl-gssapi-32bit-2.1.22-182.20.1 cyrus-sasl-saslauthd-2.1.22-182.19 cyrus-sasl-devel-2.1.22-182.20.1 cyrus-sasl-2.1.22-182.20.1 cyrus-sasl-32bit-2.1.22-182.20.1 cyrus-sasl-digestmd5-2.1.22-182.20.1 cyrus-sasl-digestmd5-32bit-2.1.22-182.20.1 Configuration files: ---------------------------- lshxx0693:~ # cat /etc/sasl2/slapd.conf mech_list: plain login pwcheck_method: saslauthd lshxx0693:~ # cat /etc/sysconfig/saslauthd SASLAUTHD_AUTHMECH=pam SASLAUTHD_THREADS=5 SASLAUTHD_PARAMS="-r" lshxx0693:~ # cat /etc/pam.d/ldap auth required pam_krb5.so no_user_check account required pam_permit.so lshxx0693:/etc/pam.d/ # cat common-account | egrep -v "^#" account requisite pam_unix2.so account sufficient pam_localuser.so account required pam_ldap.so use_first_pass lshxx0693:/etc/pam.d/ # cat common-account-pc | egrep -v "^#" account requisite pam_unix2.so account sufficient pam_localuser.so account required pam_ldap.so use_first_pass lshxx0693:/etc/pam.d/ # cat common-auth | egrep -v "^#" auth required pam_env.so auth sufficient pam_unix2.so auth required pam_ldap.so use_first_pass lshxx0693:/etc/pam.d/ # cat common-auth-pc | egrep -v "^#" auth required pam_env.so auth sufficient pam_unix2.so auth required pam_ldap.so use_first_pass shxx0693:/etc/pam.d/ # cat common-password | egrep -v "^#" password requisite pam_pwcheck.so nullok cracklib password sufficient pam_unix2.so use_authtok nullok password required pam_ldap.so try_first_pass use_authtok lshxx0693:/etc/pam.d/ # cat common-session | egrep -v "^#" session optional pam_mkhomedir.so session required pam_limits.so session required pam_unix2.so session optional pam_ldap.so session optional pam_umask.so lshxx0693:/etc/pam.d/ # cat common-session-pc | egrep -v "^#" session optional pam_mkhomedir.so session required pam_limits.so session required pam_unix2.so session optional pam_ldap.so session optional pam_umask.so lshxx0693:/etc/pam.d/ # cat common-password-pc | egrep -v "^#" password requisite pam_pwcheck.so nullok cracklib password sufficient pam_unix2.so use_authtok nullok password required pam_ldap.so try_first_pass use_authtok lshxx0693:~ # pam-config --verify lshxx0693:~ # lshxx0693:~ # cat /etc/krb5.conf [libdefaults] default_realm = INT.IT.DPP dns_lookup_kdc = true [realms] INT.IT.DPP = { kdc = 10.150.10.10 kdc = 10.150.10.10 } [logging] default = SYSLOG:NOTICE:DAEMON lshxx0693:~ # cat /etc/nsswitch.conf | egrep -v "#" passwd: compat group: files ldap hosts: files dns networks: files dns services: files ldap protocols: files rpc: files ethers: files netmasks: files netgroup: files ldap publickey: files bootparams: files automount: files nis aliases: files ldap passwd_compat: ldap Tell me, if you need more informations, please. I would like to thank you in advance for your help. Best wishes S. Kuechler

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical