Cannot authenticate user with sogo and a remote AD

Hi all

I try to authenticate user in sogo with a remote account provider Samba AD and it fails

sogo.log

[root@NS7DEV9 ~]# tailf /var/log/sogo/sogo.log 
Jun 08 20:16:38 sogod [13286]: <0x0x7f558c2bfe70[LDAPSource]> <NSException: 0x7f558be1b150> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "samaccountname=toto,dc=stephdl,dc=dyndns,dc=org"; }
Jun 08 20:16:38 sogod [13286]: [ERROR] <0x0x7f558c226de0[LDAPSource]> Could not bind to the LDAP server ldap://nsdc-ns7dev8.stephdl.dyndns.org (389) using the bind DN: STEPHDL\NS7DEV9$
Jun 08 20:16:38 sogod [13286]: [ERROR] <0x0x7f558c226de0[LDAPSource]> <NSException: 0x7f558c3067c0> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "STEPHDL\\NS7DEV9$"; }
Jun 08 20:16:38 sogod [13286]: SOGoRootPage Login from '192.168.12.25' for user 'toto' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0
Jun 08 20:16:38 sogod [13286]: 192.168.12.25 "POST /SOGo/connect HTTP/1.1" 403 34/69 0.008 - - 0
Jun 08 20:16:50 sogod [13286]: <0x0x7f558c2bfe70[LDAPSource]> <NSException: 0x7f558c243830> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "samaccountname=toto@stephdl.dyndns.org,dc=stephdl,dc=dyndns,dc=org"; }
Jun 08 20:16:50 sogod [13286]: [ERROR] <0x0x7f558c226de0[LDAPSource]> Could not bind to the LDAP server ldap://nsdc-ns7dev8.stephdl.dyndns.org (389) using the bind DN: STEPHDL\NS7DEV9$
Jun 08 20:16:50 sogod [13286]: [ERROR] <0x0x7f558c226de0[LDAPSource]> <NSException: 0x7f558c3060d0> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "STEPHDL\\NS7DEV9$"; }
Jun 08 20:16:50 sogod [13286]: SOGoRootPage Login from '192.168.12.25' for user 'toto@stephdl.dyndns.org' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0
Jun 08 20:16:50 sogod [13286]: 192.168.12.25 "POST /SOGo/connect HTTP/1.1" 403 34/88 0.009 - - 0

If I change in the /etc/sogo/sogo.conf

-        hostname = ldap://nsdc-ns7dev8.stephdl.dyndns.org;
+       hostname = ldaps://nsdc-ns7dev8.stephdl.dyndns.org;

then the login is successful.

on the remote AD SAMBA

[root@NS7DEV8 ~]# account-provider-test dump
{
   "BindDN" : "STEPHDL\\NS7DEV8$",
   "LdapURI" : "ldaps://stephdl.dyndns.org",
   "StartTls" : "",
   "port" : 636,
   "host" : "stephdl.dyndns.org",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "dc=stephdl,dc=dyndns,dc=org",
   "GroupDN" : "dc=stephdl,dc=dyndns,dc=org",
   "BindPassword" : "hRmZHxK%nEN+8L",
   "BaseDN" : "dc=stephdl,dc=dyndns,dc=org",
   "LdapUriDn" : "ldap:///dc%3Dstephdl%2Cdc%3Ddyndns%2Cdc%3Dorg"
}

on the local server with sogo (the account provider is a remote AD Samba)

[root@NS7DEV9 ~]# account-provider-test dump
{
   "BindDN" : "STEPHDL\\NS7DEV9$",
   "LdapURI" : "ldap://nsdc-ns7dev8.stephdl.dyndns.org",
   "StartTls" : "",
   "port" : 389,
   "host" : "nsdc-ns7dev8.stephdl.dyndns.org",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=stephdl,DC=dyndns,DC=org",
   "GroupDN" : "DC=stephdl,DC=dyndns,DC=org",
   "BindPassword" : "UNjGG~ZK>p?u]p",
   "BaseDN" : "DC=stephdl,DC=dyndns,DC=org",
   "LdapUriDn" : "ldap:///dc%3Dstephdl%2Cdc%3Ddyndns%2Cdc%3Dorg"
}

you can see that sogo takes its url from above, but it fails, we should force ldaps

@dev_team what do you think ?

That LdapURI seems missing the ldaps schema. What is your

config show sssd
[root@NS7DEV9 ~]# config show sssd
sssd=service
    AdDns=192.168.12.86
    BaseDN=DC=stephdl,DC=dyndns,DC=org
    BindDN=
    BindPassword=
    GroupDN=DC=stephdl,DC=dyndns,DC=org
    LdapURI=ldap://nsdc-ns7dev8.stephdl.dyndns.org
    Provider=ad
    Realm=STEPHDL.DYNDNS.ORG
    StartTls=
    UserDN=DC=stephdl,DC=dyndns,DC=org
    Workgroup=STEPHDL
    status=enabled

If I recall well, with a remote openldap I had not issues, only with the remote samba AD

I think your problem started when I reverted a previous fix, by removing this option from DC configuration

ldap server require strong auth=no

In general, that option allows clear-text simple binds over the network, like Microsoft AD does. However Microsoft AD does not allow this kind of bind using machine credentials.

Our docs says about remote providers:

Once NethServer has successfuly joined AD, specify the dedicated user account credentials in Accounts provider > Read-only bind credentials.

It seems you’re still missing this step. However the underlying library still tries to connect with machine credentials and succeeded – until my commit above…


I tried to join NethServer to a remote Samba AD provider and this is the result

With AD accounts provider, STARTTLS=default means “disabed”.

If you need a quick fix either set STARTTLS=yes or ldaps::// schema and save. You still send machine credentials, but over a ciphered socket.

However I feel something still needs to be fixed…

I’d prefer to not reintroduce ldap server require strong auth=no, and retain Samba upstream default: it is more secure.

Instead, while retaining the NethServer::SSSD behavior, the UI could probe STARTTLS availability, so that new installations have a secure channel. The effect would be

  • for Samba AD it works out of the box with machine credentials over STARTTLS (but as recommended by the docs a dedicated user account is preferred)
  • for Microsoft AD a dedicated user account is always mandatory and STARTTLS could not be available (very common case). In any case to talk with AD some kind of input is always required.

In future versions, I wouldn’t use machine credentials any more!

2 Likes

It doesn’t work with the STARTLS=yes, but it succeed if I change the ldap schema to ldaps:://

Even if I create a Read-only bind credentials, I cannot authenticate except if I change the ldap schema.

what can we do, documented it in sogo wiki page, or try to solve something ?

I don’t remember if Sogo has a STARTTLS support.

For instance, ejabberd does not have it. IIRC the template attempts an ldaps connection if STARTTLS is selected, as last resort.

On the server side I’d try to add ldaps/STARTTLS probing to the ui wizard procedure, and remove default machine credentials in NS 7.4.

Running NethServer release 7.4.1708 (Final)

I just installed and updated this version on two servers.
The first one was set up to run an AD domain.
The second one I installed Sogo on and then joined it to the domain created on the first.

I can confirm that the only way to logon to the SOGo webinterface is to set the LDAP scheme to LDAPS and disable starttls on the accounts provider page.

1 Like

yep it should be documented or better fixed

@giacomo just did it :smile:

https://github.com/NethServer/dev/issues/5365

3 Likes

well we should look after "StartTls" : "1",

# account-provider-test dump on NS2
{
   "BindDN" : "ldapservice@AD.DOMAIN.EU",
   "LdapURI" : "ldap://nsdc-ns1.ad.domain.tld",
   "StartTls" : "1",
   "port" : 389,
   "host" : "nsdc-ns1.ad.domain.tld",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=tld",
   "GroupDN" : "DC=ad,DC=domain,DC=tld",
   "BindPassword" : "#############",
   "BaseDN" : "DC=ad,DC=domain,DC=tld",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dtld"
}

the sogo documentation states

hostname
	

A space-delimited list of LDAP URLs or LDAP hostnames.

LDAP URLs are specified in RFC 4516 and have the following general format:

scheme://host:port/DN?attributes?scope?filter?extensions

Note that SOGo doesn’t currently support DN, attributes, scope and filter in such URLs. Using them may have undefined side effects.

URLs examples:

    ldap://127.0.0.1:3389

    ldaps://127.0.0.1

    ldap://127.0.0.1/????!StartTLS

well we should look after the

 +        if($sssd->startTls()) {
 +            $OUT .= "ldap://nsdc-ns1.ad.domain.tld/????!StartTLS";
 +        }

not tested but we should try… @planet_jeroen are you ready to test it ?

1 Like

I would like that someone test it… @Arnaud @planet_jeroen could you help me

yum install http://packages.nethserver.org/nethserver/7.5.1804/nethforge-autobuild/x86_64/Packages/nethserver-sogo-1.7.2-1.2.pr26.g53c03f8.ns7.noarch.rpm

Actually if sogo is not installed on the samba AD server, we cannot authenticate because we lack startTLS on 389.

Heya m8. I have been away a bit, due to stuff happening … right now I am trying to update my servers to be current again, but running into a few issues … as soon as those are resolved, I will help you out.

What exactly do you need for a test scenario ? As right now, I do not have SOGo and my AD provider on the same machine, so I would have to create that scenario first (no problem, just let me know)

the scenario is

  • Install AD on NS1
  • Connect the AD on NS2
  • install sogo on NS2, you must login with users of NS1

This is my default scenario … so if I am able to update my servers and it still works, that would be considered tested ?

1 Like

yes, you must see this kind of url in sogo.conf

    hostname = ldap://ad.de-labrusse.fr/????!StartTLS;

if the ldap parameters are

   "StartTls" : "1",
   "port" : 389,

# account-provider-test dump on NS2
{
   "BindDN" : "ldapservice@AD.DOMAIN.EU",
   "LdapURI" : "ldap://nsdc-ns1.ad.domain.tld",
   "StartTls" : "1",
   "port" : 389,
   "host" : "nsdc-ns1.ad.domain.tld",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=tld",
   "GroupDN" : "DC=ad,DC=domain,DC=tld",
   "BindPassword" : "#############",
   "BaseDN" : "DC=ad,DC=domain,DC=tld",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dtld"
}
1 Like

Then all I need now is find a way to update my servers without ending up with read only filesystem, and then I will test this with pleasure!

1 Like

I will probably update my environment today. Please confirm if this is the way to do it:

  1. Backup servers, duh
  2. Change account provider setting on NS2 from the workaround (ldaps://) to ldap:// and set starttls in the drop-down.
  3. Update servers
    3b. (Optional) pray
  4. Check if everything works after updating both NS1 and 2

…right? No different repo’s needed ?

1 Like

yep just upgrade from the sogo link I gave, and think to modify the ldaps to ldap (check starttls)

you can check it on ns2 (NS without sambaAD) by :

account-provider-test dump

{
“BindDN” : "ldapservice@AD.xxxxxxx.FR",
“LdapURI” : “ldaps://ad.xxxxxxxx.fr”,
“StartTls” : “1”,
“port” : 389,
“host” : “ad.xxxxx.fr”,
“isAD” : “”,
“isLdap” : “”,
“UserDN” : “dc=ad,dc=xxxxx,dc=fr”,
“GroupDN” : “dc=ad,dc=xxxxx,dc=fr”,
“BindPassword” : “xxxxxxx”,
“BaseDN” : “dc=ad,dc=xxxx,dc=fr”,
“LdapUriDn” : “ldap:///dc%3Dad%2Cdc%3Dxxxxxx%2Cdc%3Dfr”
}

I ran into this issue today (trying to authenticate to a remote non-NS AD server) and on doing a search I came across this post.

I have tested my Sogo with this update (after backup :grinning:) and can gladly report that this fix is working !

2 Likes