SSO not working with AD auth about adldap2-laravel HOT 9 CLOSED

Hi @adepertat,

which doesn't work because in Active Directory, the objectCategory field contains the dn to a schema (more like CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com).

Are you seeing this DN from the "Active Directory Users and Computers interface"?

from adldap2-laravel.

Yes. Please note the difference between objectCategory and objectClass :

from adldap2-laravel.

Hmmm, this should work then. Active Directory allows you to bypass querying the entire distinguished name of the objectcategory:

https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

You can use a filter clause similar to the following:

(objectCategory=cn=person,cn=Schema,cn=Configuration,dc=MyDomain,dc=com)

However, Active Directory allows you to instead use the following shortcut:

(objectCategory=person)

Can you try executing a raw query to attempt locating the user you're looking for? Ex:

$user = Adldap::search()->where('cn', '=', 'John Doe')->first();

If no users are being returned, can you verify that the account you're connecting to your Active Directory server with has the appropriate permissions to query inside of the OU's you're looking to query?

from adldap2-laravel.

Indeed. I tested the query with both short and long versions of objectCategory in ADSIEdit and it works.

I am confident this is not a permission problem because the standard authentication (through the login form) works. It stops working when I try to use the SSO through an HTTP header.

Here is a debug log through SSO (does not work) : https://gist.github.com/adepertat/c2d0132eac6cf6f2ca23951616c9ac68

And here it is through the login form (works) : https://gist.github.com/adepertat/4da4127eecd71bd78fc79bc38c29deaa

from adldap2-laravel.

Indeed. I tested the query with both short and long versions of objectCategory in ADSIEdit and it works.

Ok that's great to hear it's working properly. Thanks for also posting the logs @adepertat.

Can you share the code/where the query is taking place inside of the Freescout system for SSO and non-SSO authentication attempts?

from adldap2-laravel.

For the SSO part, the code is failing to retrieve the user because some query returns nothing instead of the user account, specifically in this file https://gist.github.com/adepertat/8504f82140026ae62e7617e2a17cf7fa in the method resolveUserByUsername. The query is built with an instance of this Builder class : https://gist.github.com/adepertat/c3aabfc65872a3f062b5ba44af52bff8.

This code

Resolver::query()->where([$this->discover() => $username])

yields this object : https://gist.github.com/adepertat/35904b146fde00352dc2c41715a56741 but when the query is run, it returns no result.

I am not sure where to look for the non-SSO part.

from adldap2-laravel.

Ok, were you able to execute the query I mentioned above to see if the user you're attempting to authenticate with is able to be found?

$user = Adldap::search()->where('samaccountname', '=', 'jdoe')->first();

from adldap2-laravel.

OK the problem lies in the base DN sent by Freescout. It uses the path of the account used to read the directory, which is not where my users are. I guess it's a Freescout issue after all. Thanks a lot @stevebauman for taking the time to help me.

from adldap2-laravel.

Ok sounds good, no problem @adepertat! Happy to help. Glad you're getting closer to a resolution.

Closing for now but feel free to comment back if you have any further questions and I'll assist you 👍

from adldap2-laravel.