Bind on Linux (Docker container) throws LdapException

[x-fusion]

Describe the bug Binding doesn't work on Linux

To Reproduce using (var cn = new LdapConnection()) { cn.Connect("xxx.zzz.ccc.com", 389); cn.Bind(LdapAuthType.Digest, new LdapCredential { UserName = "xxxxxxxxx", AuthorizationId = "dc=xx,dc=xxx,dc=xxxx", Password = "xxxx2009" }); var user = cn.WhoAmI().Result; }

Expected behavior It should return user id after running WhoAmI

Desktop (please complete the following information):

• OS: Windows 10
• Library version [e.g. 2.3]
• .NET\core\mono version 3.1
• LDAP server ??

Additional context Code runs fine when ran in IISExpress, but not in Docker linux container

[flamencist]

Hi! Did you catch exception or just timeout?

[x-fusion]

LdapException with such message: Unknown authentication method. SASL(-4): no mechanism available. Maybe because docker container doesn't have openldap? If so, when system would be placed in real linux server would installing openldap be sufficed?

[ch0mik]

I have similar error :

` public ActionResult<Dictionary<string,string>> WhoAmI() { Dictionary<string, string> result = new Dictionary<string, string>();

        result.Add("OS Platform", Environment.OSVersion.Platform.ToString());


        using (var cn = new LdapConnection())
        {
            // connect
            cn.Connect();
            // bind using kerberos credential cache file
            cn.Bind();

            result.Add("WhoAmI", cn.WhoAmI().Result);
        }

        return result;
    }

`

this code works on Windows, but Linux Container not ...

LdapForNet.LdapException: Can't contact LDAP server. Result: -1. Method: BindSasl at LdapForNet.Native.LdapNative.ThrowIfError(SafeHandle ld, Int32 res, String method, IDictionary2 details) at LdapForNet.LdapConnection.Bind(LdapAuthType authType, LdapCredential credential) at LdapForNet.LdapConnection.Bind(String mechanism, String userDn, String password) at MQSeriesClient.Controllers.ClientController.WhoAmI() in /app/Controllers/ClientController.cs:line 34 `

kerberos ticket are ok :

Ticket cache: FILE:/tmp/krb5cc_1001 Default principal: [email protected]

Valid starting Expires Service principal 09/23/20 16:55:14 09/24/20 02:55:14 krbtgt/[email protected] renew until 09/30/20 16:55:14

this ticket works fine with SQL Server

[flamencist]

Check your openldap configuration. I think the errors are not related to ldap4net. Try to check using ldap-utils, for example ldapsearch

[x-fusion]

@flamencist I am trying to run this project in docker container, which is in linux. I think I have no power in ldap configuration. If you have a spare minute just create net core project and run my code, but not in IIS, but Docker you would see that it doesn't work. I am trying to figure out if something additional needs to be installed or what kind approach I would have to take when I deploy sistem in linux server

[flamencist]

Try to check sasl and ldap packages. https://github.com/flamencist/ldap4net/blob/834c0964ab796f4d94079f3a0848d9f062025757/.travis.yml#L10

[x-fusion]

Could you provide some instructions? I looked into it and I can see that I am clueless...

[flamencist]

First of all, need to install packages. For example ubuntu:

sudo apt install -y ldap-utils sasl2-bin libsasl2-2 libsasl2-modules libsasl2-modules-ldap openssl

[x-fusion]

Okay now its clear for me, that Linux has to have some packages installed. I will keep that in mind. Please don't delete this issue, I will use it as source material. Thank you!

[mhl-c]

Hi @flamencist,

I have a similar problem. On Windows everything is working fine, but if I run my application in a linux docker container (Ubuntu) I get the following error: "Unknown authentication method. SASL(-4): no mechanism available: No worthy mechs found. Result: -6. Method: BindSasl"

I have installed all the libraries you mentioned above. Furthermore I can run a ldapsearch command inside the container and this request is working.

My ldap4net request looks like this:

            using (var cn = new LdapConnection())
            {
                var port = ldapConfig.Port ?? 389;

                cn.Connect(ldapConfig.Host, port);

                cn.Bind(LdapAuthType.Digest, new LdapCredential
                {
                    UserName = ldapConfig.User,
                    Password = ldapConfig.Password,    
                });
                return cn.Search(ldapConfig.SearchBase, $"(userPrincipalName={filterValue})");
            }

Do you have any suggestions?

[x-fusion]

Hi @flamencist,

I have a similar problem. On Windows everything is working fine, but if I run my application in a linux docker container (Ubuntu) I get the following error: "Unknown authentication method. SASL(-4): no mechanism available: No worthy mechs found. Result: -6. Method: BindSasl"

I have installed all the libraries you mentioned above. Furthermore I can run a ldapsearch command inside the container and this request is working.

My ldap4net request looks like this:

            using (var cn = new LdapConnection())
            {
                var port = ldapConfig.Port ?? 389;

                cn.Connect(ldapConfig.Host, port);

                cn.Bind(LdapAuthType.Digest, new LdapCredential
                {
                    UserName = ldapConfig.User,
                    Password = ldapConfig.Password,    
                });
                return cn.Search(ldapConfig.SearchBase, $"(userPrincipalName={filterValue})");
            }

Do you have any suggestions?

If you can bind and make search, what seems to be a problem?

[mhl-c]

If you can bind and make search, what seems to be a problem?

Bind and search works on Windows with ldap4net but not on linux. On linux only ldapsearch is working. But I have no idea what the root cause is for this.

[flamencist]

I guess that you have problems with sasl digest auth. Try use ldapsearch with digest-md5 mechanism.

[mhl-c]

Hi @flamencist, thank you very much for the hint! Ldapserach with digest-md5 did not work in our environment either. So we switched to the authentification type simple and followed the steps from bug ticket #65. Now everything works!