Bug#586532: nslcd: Configure SASL with debconf
Daniel Dehennin
Version: 0.7.6
Severity: wishlist
Hello,
Here is a patch to permit the configuration of SASL authentication with
debconf.
The configuration is limited to GSSAPI for now, I'll try to setup
saslauthd to look at other mechanism.
Regards.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.33.2+hati.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages nslcd depends on:
ii adduser 3.112 add and remove users and groups
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib
ii libgssapi-krb5-2 1.8.1+dfsg-5 MIT Kerberos runtime libraries - k
ii libldap-2.4-2 2.4.21-1 OpenLDAP libraries
Versions of packages nslcd recommends:
ii libnss-ldapd 0.7.6 NSS module for using LDAP as a nam
pn libpam-ldapd <none> (no description available)
pn nscd <none> (no description available)
nslcd suggests no packages.
-- debconf information:
nslcd/ldap-starttls: false
nslcd/ldap-reqcert:
* nslcd/ldap-uris: ldap://127.0.0.1/
nslcd/ldap-binddn:
* nslcd/ldap-base: dc=baby-gnu,dc=org
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
Daniel Dehennin
I manage to have a working DIGEST-MD5 and CRAM-MD5, CRAM-MD5 needs
minssf=0.
I'll send a new patch with all the choices[1].
Regards.
Footnotes:
[1] http://www.iana.org/assignments/sasl-mechanisms
Daniel Dehennin
Here is my new patch:
- add cyrus SASL mechanisms to the list.
- ANONYMOUS disable SASL
- LOGIN, PLAIN and *-MD5 require bindpw and sasl_authcid
Note that LOGIN and PLAIN are restricted by OpenLDAP to TLS connections,
so I didn't test them.
I didn't test OTP too.
Regards.
Daniel Dehennin
I made some more tests with PLAIN and LOGIN:
- require sasl_secprops with one of the following:
* none
* noanonymous
- slapd do not disable them when no TLS as I read
- slapd use saslauthd (with *-MD5, it use /etc/sasldb2 directly)
- PLAIN ask for optional authzid, not LOGIN
Here is my final (for now ;-)) patch, I added some requirement informations (minssf
and secprops) for some mechanisms but do not set them automatically when
selecting mechanisms.
Thanks.
Arthur de Jong
> Here is my final (for now ;-)) patch, I added some requirement
> informations (minssf and secprops) for some mechanisms but do not set
> them automatically when selecting mechanisms.
Thanks a lot for your patch. I have not yet had the time to look at it
in detail though.
I did notice that you have a separate ldap-sasl and ldap-sasl-mech
question. I think it would be nicer (to follow the change in
configuration to get rid of use_sasl) to have only one question which
asks about the mechanism with a value of "No SASL" or something
equivalent.
I think it is a good idea to keep the te debconf questions close to
configuration options. This is probably also clearer to the user and
limits the number of questions.
Perhaps it is also a good idea to move the password question after the
SASL one or maybe even move the binddn question after SASL. If we keep
the binddb question before SASL is it safe to skip the SASL question if
the binddn is empty (is there any reasonable configuration with an empty
binddn while using SASL)?
Anyway, thanks again for all your effort on the SASL bits.
--
-- arthur - ade...@debian.org - http://people.debian.org/~adejong --
Daniel Dehennin
[...]
> I did notice that you have a separate ldap-sasl and ldap-sasl-mech
> question. I think it would be nicer (to follow the change in
> configuration to get rid of use_sasl) to have only one question which
> asks about the mechanism with a value of "No SASL" or something
> equivalent.
>
> I think it is a good idea to keep the te debconf questions close to
> configuration options. This is probably also clearer to the user and
> limits the number of questions.
Ok, I'll follow your advices, and send a new version of the patch.
> Perhaps it is also a good idea to move the password question after the
> SASL one or maybe even move the binddn question after SASL. If we keep
> the binddb question before SASL is it safe to skip the SASL question if
> the binddn is empty (is there any reasonable configuration with an empty
> binddn while using SASL)?
binddn is not used with SASL, authentication is done with:
- ticket cache information for Kerberos
- authcid for LOGIN, PLAIN, *-MD5
Here is a log for a working PLAIN authentication:
--8<---------------cut here---------------start------------->8---
nslcd: [3c9869] DEBUG: ldap_initialize(ldap://192.168.122.4)
nslcd: [3c9869] DEBUG: ldap_set_rebind_proc()
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_X_SASL_SECPROPS,"noanonymous")
nslcd: [3c9869] DEBUG: ldap_sasl_interactive_bind_s(NULL,"PLAIN") (uri="ldap://192.168.122.4")
nslcd: [3c9869] DEBUG: do_sasl_interact(): were asked for sasl_authzid but we don't have any
nslcd: [3c9869] DEBUG: do_sasl_interact(): returning sasl_authcid "dad"
nslcd: [3c9869] DEBUG: do_sasl_interact(): returning bindpw "***"
nslcd: [3c9869] DEBUG: ldap_result(): end of results
--8<---------------cut here---------------end--------------->8---
Commenting binddn, bindpw, authcid and authzid:
--8<---------------cut here---------------start------------->8---
nslcd: [8b4567] DEBUG: ldap_sasl_interactive_bind_s(NULL,"PLAIN") (uri="ldap://192.168.122.4")
nslcd: [8b4567] DEBUG: do_sasl_interact(): were asked for sasl_authzid but we don't have any
nslcd: [8b4567] DEBUG: do_sasl_interact(): were asked for sasl_authcid but we don't have any
nslcd: [8b4567] DEBUG: do_sasl_interact(): were asked for bindpw but we don't have any
--8<---------------cut here---------------end--------------->8---
Using binddn and bindpw:
--8<---------------cut here---------------start------------->8---
nslcd: [8b4567] DEBUG: ldap_sasl_interactive_bind_s("uid=daniel,ou=users,dc=baby-gnu,dc=org","PLAIN") (uri="ldap://192.168.122.4")
nslcd: [8b4567] DEBUG: do_sasl_interact(): were asked for sasl_authzid but we don't have any
nslcd: [8b4567] DEBUG: do_sasl_interact(): were asked for sasl_authcid but we don't have any
nslcd: [8b4567] DEBUG: do_sasl_interact(): returning bindpw "***"
--8<---------------cut here---------------end--------------->8---
So, binddn or SASL and bindpw used for both.
Regards.
Daniel Dehennin
> Perhaps it is also a good idea to move the password question after the
> SASL one or maybe even move the binddn question after SASL. If we keep
> the binddb question before SASL is it safe to skip the SASL question if
> the binddn is empty (is there any reasonable configuration with an empty
> binddn while using SASL)?
Looking at RFC4313 section 5.2.1.2. SASL Authentication Initiation and
Protocol Exchange(page 16):
Clients sending a BindRequest message with the sasl choice selected
SHOULD send a zero-length value in the name field. Servers receiving
a BindRequest message with the sasl choice selected SHALL ignore any
value in the name field.
So, when using SASL, binddn should be empty.
Regards.
Daniel Dehennin
> I think it is a good idea to keep the te debconf questions close to
> configuration options. This is probably also clearer to the user and
> limits the number of questions.
I made some more tests, using a separate question for the auth type
permit to remember settings in debconf, for exemple:
- nslcd/ldap-auth-type:
* none: nslcd/ldap-binddn and nslcd/ldap-sasl-mech disabled
* simple: nslcd/ldap-binddn enabled and nslcd/ldap-sasl-mech disabled
* SASL: nslcd/ldap-binddn disabled and nslcd/ldap-sasl-mech enabled
This facilitate the switch from one auth-type to another without loosing
configuration.
This permit to answer only one question to disable authentication,
instead of two (empty binddn and SASL mech=none)
I attached the patch which implement your proposal, mutually exclusives
binddn and sasl.
I'm working now on nslcd/ldap-auth-type verision.
Regards.
Arthur de Jong
> Arthur de Jong <ade...@debian.org> writes:
>
> > I think it is a good idea to keep the te debconf questions close to
> > configuration options. This is probably also clearer to the user and
> > limits the number of questions.
>
> I made some more tests, using a separate question for the auth type
> permit to remember settings in debconf, for exemple:
> - nslcd/ldap-auth-type:
> * none: nslcd/ldap-binddn and nslcd/ldap-sasl-mech disabled
> * simple: nslcd/ldap-binddn enabled and nslcd/ldap-sasl-mech disabled
> * SASL: nslcd/ldap-binddn disabled and nslcd/ldap-sasl-mech enabled
>
> This facilitate the switch from one auth-type to another without loosing
> configuration.
This sounds like a good idea. I would welcome a patch for that. Thanks a
lot for working on this.
Daniel Dehennin
> This sounds like a good idea. I would welcome a patch for that. Thanks a
> lot for working on this.
Here is the changelog, patch based on latest svn (revno:1161):
* debian/nslcd.templates: Add nslcd/ldap-auth-type and SASL templates.
* debian/nslcd.config: Manage SASL questions, bindpw is shared between
binddn and sasl, it's asked just after binddn or authcid, this
complexify a little the switch case.
* debian/nslcd.postinst: Manage SASL options, binddn and SASL disable
each other. Use 2 functions simple_auth and sasl_auth to simplify
the configuration.
NB: I added an SASL auto mechanism but I'm not sure if it's useful, feel
free to remove it, it's the default mech in the template.
Daniel Dehennin
Hello,
> First, the detection routines are now a little cleaner I think. All
> options are read from the config, even if they don't make much sense
> combined. We want to try to retain as much as possible from the
> administrator's changes to the file.
I have a problem with this, it override the debconf memory, if I enable
SASL mechanism, then switch to simple and then switch back to
SASL, some information is lost like the SASL realm.
This is due to the variable reset.
Maybe we should detect "enabled" configuration and override the debconf
setting for them only. I'll code this and send a patch soon.
> Secondly, I've changed the question grouping a bit. I've also removed
> krb5keytab for now because it isn't used.
>
[...]
> I've also simplified the back code a bit (mostly skip back to authtype).
Great!
> The question now is, are the questions clear enough in most common
> situations? For anonymous bind and simple authentication I think it is
> clear enough, but what about Kerberos authentication? Also, perhaps the
> list of SASL mechs should be in a most-commonly used first order? Is the
> order of the SASL questions reasonable?
The actual order is from less secure to most secure, grouping by
types (login/password for LOGIN to DIGEST-MD5).
For most-commonly used first order, this should be GSSAPI then most
secure login/password (DIGEST-MD5) to less secure one (PLAIN) and
finally OTP.
I added an auto mechanism but I don't know if it's usefull, this
mechanism should ask all the SASL questions and the protocol will pick
the right one.
> I have not really looked at the other files yet (templates and
> postinst). I think the questions could use some improvements but it is
> also related to the question flow. I did notice that the ldap-sasl-mech
> and ldap-sasl-secprops are really long.
ldap-sasl-secprops is cut&past from ldap.conf manpage.
> Anyway, thanks for your work. This should get reasonable close to
> inclusion in the next release.
Thanks, I hope this will bring nss-pam-ldapd to "best suited for
SASL/LDAP environment" ;-)
Daniel Dehennin
> First, the detection routines are now a little cleaner I think. All
> options are read from the config, even if they don't make much sense
> combined. We want to try to retain as much as possible from the
> administrator's changes to the file.
Hello, I attache a patch against your nslcd.config, I can provide one
against trunk if you prefer.
Settings defined in the configuration file are retained, others stay in
debconf.
The only trickery thing I encounter with my change is the
nslcd/ldap-auth-type autodetection.
Both types can be defined, one from debconf and one from the
configuration file. In that case, I use debconf auth-type if any or
none.
The administrator only needs to select the desired one interactively.
To overcome any manually modified settings, an "non interactive debconf" administrator only
needs to preseed nslcd/ldap-auth-type to none, reconfigure non
interactively, then preseed again with the good settings and
reconfigure.
Arthur de Jong
> Hello, I attache a patch against your nslcd.config, I can provide one
> against trunk if you prefer.
Hi, just to give you a heads up on this issue I'm afraid we are too late
for squeeze since it is frozen now. I'm sorry but haven't had time to
look into this before the freeze.
I have some other bugs in nss-pam-ldapd that I want to have fixed in
squeeze first but after that I can probably address this in unstable
(doing the change then also means there is more time to test it).
Daniel Dehennin
> Hi, just to give you a heads up on this issue I'm afraid we are too late
> for squeeze since it is frozen now. I'm sorry but haven't had time to
> look into this before the freeze.
>
> I have some other bugs in nss-pam-ldapd that I want to have fixed in
> squeeze first but after that I can probably address this in unstable
> (doing the change then also means there is more time to test it).
Hello,
Fine, I already use it and cfengine handle the configuration ;-)
I don't know if the auto SASL mechanism will stay, it require to ask all
the possible question and may need a special case in nslcd code (NULL
mech?).
Arthur de Jong
> Arthur de Jong <ade...@debian.org> writes:
>
> > Hi, just to give you a heads up on this issue I'm afraid we are too late
> > for squeeze since it is frozen now. I'm sorry but haven't had time to
> > look into this before the freeze.
> >
> > I have some other bugs in nss-pam-ldapd that I want to have fixed in
> > squeeze first but after that I can probably address this in unstable
> > (doing the change then also means there is more time to test it).
>
I have been working on getting your SASL configuration patch integrated
into the packaging (I'm aiming it for a 0.8 development release
soonish).
I'm now mostly happy with the .config and .postinst files but I think
the .templates files has some issues still. The text is rather long and
even lintian complains about the nslcd/ldap-sasl-mech and
nslcd/ldap-sasl-secprops templates.
Can you see if you have any improvements for the templates file? Perhaps
some external reference can be included or we may have to assume that an
administrator knows about the different SASL options?
Perhaps it should be clearer what to do when you want to use Kerberos?
Anyway, hope to hear from you on this!
Daniel Dehennin
[...]
> I'm now mostly happy with the .config and .postinst files but I think
> the .templates files has some issues still. The text is rather long and
> even lintian complains about the nslcd/ldap-sasl-mech and
> nslcd/ldap-sasl-secprops templates.
>
> Can you see if you have any improvements for the templates file? Perhaps
> some external reference can be included or we may have to assume that an
> administrator knows about the different SASL options?
>
> Perhaps it should be clearer what to do when you want to use Kerberos?
>
> Anyway, hope to hear from you on this!
I have simplify the template and fix the read_config function.
The SASL questions (in switch case) are lost in trunk, should I provide
a new patch on yours for this or do you have it somewhere?
Arthur de Jong
> I have simplify the template and fix the read_config function.
Thanks. I've done some more work on the templates and fixed the
read_config function in a slightly different way and committed it to the
repository. This also includes the changes to the .config and .postinst
scripts.
I would like to gather feedback on the templates and general
configuration scheme from some people. I'll probably upload a version
0.8.0 to experimental in the coming weeks somewhere (no definite date
set yet but I would also like to get some more pending changes ready).
Can you check out the SVN version and see if there are any things I
missed? Currently the tool completely replaces the debconf data every
time but I think this makes the logic as understandable as possible for
now.
Anyway, thanks for your work on this.
Daniel Dehennin
> Can you check out the SVN version and see if there are any things I
> missed? Currently the tool completely replaces the debconf data every
> time but I think this makes the logic as understandable as possible
> for now.
The auto SASL mechanism need support in the code:
nslcd: [8b4567] <group(all)> DEBUG: ldap_initialize(ldap://192.168.122.4)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_rebind_proc()
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
nslcd: [8b4567] <group(all)> DEBUG: ldap_sasl_interactive_bind_s(NULL,"auto") (uri="ldap://192.168.122.4")
nslcd: [8b4567] <group(all)> failed to bind to LDAP server ldap://192.168.122.4: Unknown authentication method: Operation now in progress
CRAM-MD5 need SASL SECPROPS minssf=0, I found it empirically, maybe a
note about it could be usefull (in man page?)
Arthur de Jong
> The auto SASL mechanism need support in the code:
>
> nslcd: [8b4567] <group(all)> DEBUG: ldap_initialize(ldap://192.168.122.4)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_rebind_proc()
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
> nslcd: [8b4567] <group(all)> DEBUG: ldap_sasl_interactive_bind_s(NULL,"auto") (uri="ldap://192.168.122.4")
> nslcd: [8b4567] <group(all)> failed to bind to LDAP server ldap://192.168.122.4: Unknown authentication method: Operation now in progress
What is nslcd supposed to do with SASL automatic mode?
> CRAM-MD5 need SASL SECPROPS minssf=0, I found it empirically, maybe a
> note about it could be usefull (in man page?)
Another option would be to have the debconf script suggest a value for
secprops if CRAM-MD5 was selected and it was empty at this point. I
guess that would be OK if it wouldn't work otherwise.
Perhaps some of the text from the earlier debconf templates could be put
in the manual page.
Daniel Dehennin
>> nslcd: [8b4567] <group(all)> DEBUG: ldap_sasl_interactive_bind_s(NULL,"auto") (uri="ldap://192.168.122.4")
>> nslcd: [8b4567] <group(all)> failed to bind to LDAP server ldap://192.168.122.4: Unknown authentication method: Operation now in progress
>
> What is nslcd supposed to do with SASL automatic mode?
From ldap_bind_s(3):
=====
The mechs parameter should contain a space-separated list of candidate
mechanisms to use. If this parameter is NULL or empty the library will
query the supportedSASLMechanisms attribute from the server's rootDSE
for the list of SASL mechanisms the server supports.
=====
nslcd should then call:
=====
nslcd: [8b4567] <group(all)> DEBUG: ldap_sasl_interactive_bind_s(NULL,"") (uri="ldap://192.168.122.4")
=====
I made a quick and dirty change in nslcd/cfg.c line 854:
===== 853
else if (strcasecmp(keyword,"sasl_mech")==0)
{
get_strdup(filename,lnr,keyword,&line,&cfg->ldc_sasl_mech);
get_eol(filename,lnr,keyword,&line);
if (strcasecmp(cfg->ldc_sasl_mech,"AUTO")==0)
{
cfg->ldc_sasl_mech="";
}
}
=====
With this, I setup nslcd.conf with the following:
=====
bindpw Cr4ckM3
krb5_ccname /var/run/nslcd/nslcd.tkt
sasl_mech AUTO
sasl_realm BABY-GNU.ORG
sasl_authcid testsrv
sasl_secprops noplain,noanonymous
=====
We need to set every possibilities and start k5start to use GSSAPI.
The automatic mechanisms search only works if 'security ssf=0 sasl=0' on
the LDAP server.
I think it's not that usefull, to get supported SASL mechanisms by the
LDAP server we can use (if anonymous bind is allowed):
=====
ldapsearch -x -b "" -s base -LLL supportedSASLMechanisms
=====
I try to make it works with "space-separated list of candidate mechanisms
to use" by comment out the 'get_eol' call in cfg.c but it seems
'get_token' should be changed too. I do not get deeper in this point.
>
>> CRAM-MD5 need SASL SECPROPS minssf=0, I found it empirically, maybe a
>> note about it could be usefull (in man page?)
>
> Another option would be to have the debconf script suggest a value for
> secprops if CRAM-MD5 was selected and it was empty at this point. I
> guess that would be OK if it wouldn't work otherwise.
Well, I made some tests and find the following:
#+tblname: Maximum slapd security values by SASL mechanisms
| | secprops | ssf | sasl | tls |
| ANONYMOUS | none/noplain | 0 | 0 | 0 |
| LOGIN | none/noanonymous | 0 | 0 | 0 |
| PLAIN | none/noanonymous | 0 | 0 | 0 |
| CRAM-MD5 | noplain+noanonymous | 0 | 0 | 0 |
| NTLM | noplain+noanonymous | 0 | 0 | 0 |
| DIGEST-MD5 | noplain+noanonymous | 128 | 128 | 0 |
| GSSAPI | noplain+noanonymous+noactive+passcred | 56 | 56 | 0 |
Execpt for DIGEST-MD5 and GSSAPI, minssf must be 0.
The nodict SASL disable all the mechanisms in the previous table (maybe
useable by EXTERNAL with TLS certification verification?)
The slapd's tls security factor require TLS to be activated.
Finally, I'm fine with suggesting minssf values if empty since the
client library seems to validate the mechanism before using it, for
example:
- slapd: security ssf=0, sasl-secprops noplain,noanonymous should permit
DIGEST-MD5
- client nslcd.conf: sasl_secprops noplain,noanonymous,noactive =>
DIGEST-MD5 does not work, only GSSAPI is possible.
When testing I saw this strange behaviour.
- nslcd open the TCP connection to the server and unbind without binding:
===== wireshark
No. Time Source Destination Protocol Info
5 7.410819 192.168.122.3 192.168.122.4 TCP 51522 > ldap [SYN] Seq=0 [...]
6 7.411627 192.168.122.4 192.168.122.3 TCP ldap > 51522 [SYN, ACK] Seq=0 [...]
7 7.411648 192.168.122.3 192.168.122.4 TCP 51522 > ldap [ACK] Seq=1 [...]
8 7.421897 192.168.122.3 192.168.122.4 LDAP unbindRequest(1)
9 7.421979 192.168.122.3 192.168.122.4 TCP 51522 > ldap [FIN, ACK] Seq=8 [...]
10 7.422650 192.168.122.4 192.168.122.3 TCP ldap > 51522 [ACK] Seq=1 [...]
11 7.422663 192.168.122.4 192.168.122.3 TCP ldap > 51522 [FIN, ACK] Seq=1 [...]
12 7.422669 192.168.122.3 192.168.122.4 TCP 51522 > ldap [ACK] Seq=9 [...]
===== wireshark
and fail with the following message:
=====
nslcd: [8b4567] <group(all)> failed to bind to LDAP server
ldap://192.168.122.4: Unknown authentication method: Operation
now in progress
=====
- a ldapsearch do the following:
===== wireshark
No. Time Source Destination Protocol Info
3 2.728967 192.168.122.3 192.168.122.4 TCP 51521 > ldap [SYN] Seq=0 [...]
4 2.729699 192.168.122.4 192.168.122.3 TCP ldap > 51521 [SYN, ACK] Seq=0 [...]
5 2.729714 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=1 [...]
6 2.739576 192.168.122.3 192.168.122.4 TCP 51521 > ldap [FIN, ACK] Seq=1 [...]
7 2.740686 192.168.122.4 192.168.122.3 TCP ldap > 51521 [FIN, ACK] Seq=1 [...]
8 2.740702 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=2 [...]
===== wireshark
and fail with the following message:
===== ldapsearch
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available: No worthy
mechs found
===== ldapsearch
The ldap library open the useless connection, but nslcd add a useless
unbindRequest.