LDAP/SSO does not find user in AD

[rogatec]

I have an existing user database with a specific system_name field (which is similar to an username).

The system_name matches the samaccount name, therefore in my adldap_auth.php I configured the attributes like this:

'username_attribute' => ['system_name' => 'samaccountname'],
'login_attribute' => env('ADLDAP_LOGIN_ATTRIBUTE', 'samaccountname'),
'windows_auth_attribute' => ['system_name' => 'PHP_AUTH_USER'], // apache web server

When using the php artisan adldap:import {myusername} the respond is:

Found user 'forename surname'. Importing...
 1/1 [] 100%
Successfully imported / synchronized 0 user(s).

Why does this not work, is it necessary that I create a user table via database/migrations/2014_10_12_000000_create_users_table.php ?

Additionally while running the webpage itself I'm simulating SSO via AuthType Basic and an existing htpasswd file to tell the browser I'm logging in with the system_name. Unfortunately in the WindowsAuthenticate@handle method the following executed call returns null:

// starts @line 63
// Find the user in AD.
$user = $this->newAdldapUserQuery()
    ->whereEquals($key, $username)
    ->first();

Before those lines I checked the $key which is indeed my system_name column name and the $username is the name of my windows credential, the credential I'm giving via AuthType and the system_name stored in the database.

About adldap.php: The configuration is copied from a small test script (plain php) to test if the linux server can connect and bind to the ldap server, therefore I don't think that there is a configuration mistake.

Anything I'm missing or are there still some important information needed?

[stevebauman]

Hi @rogatec,

For your first question about importing, can you try enabling the logging option and see what error is output to the log upon import?

php artisan adldap:import {myusername} --log=true

Before those lines I checked the $key which is indeed my system_name column name and the $username is the name of my windows credential, the credential I'm giving via AuthType and the system_name stored in the database.

The key should actually be samaccountname, not system_name. The key of the windows_auth attribute array is in relation to active directory, not your local database.

Also, the newAdldapUserQuery() method generates a query that searches your AD server, not your local database.

This is documented in the configuration itself:

/*
|--------------------------------------------------------------------------
| Windows Auth Attribute
|--------------------------------------------------------------------------
|
| This array represents how a user is found when
| utilizing the Adldap Windows Auth Middleware.
|
| The key of the array represents the attribute that the user is located by.
|
|     For example, if 'samaccountname' is the key, then your LDAP server is
|     queried for a user with the 'samaccountname' equal to the
|     $_SERVER['AUTH_USER'] variable.
|
|     If a user is found, they are imported into your
|     local database, then logged in.
|
| The value of the array represents the 'key' of the $_SERVER
| array to pull the users username from.
|
|    For example, $_SERVER['AUTH_USER'].
|
| This must be an array with a key - value pair.
|
*/

'windows_auth_attribute' => ['samaccountname' => 'AUTH_USER'],

[rogatec]

@stevebauman thanks for your reply.

The import fails because the sql insert expects that there is a name column in the database.

Unfortunately the db table structure has separated the name into forename and surname, so I guess I need to override some methods from the ImportsUsers trait.

About the second mistake, I have to admit that I obviously didn't read the comments wisely. I fixed the configuration and now I am getting the same QueryException due to the above hinted information, that I have a different user table structure.

Nevertheless in the first place I don't want the library to import the ad user into my database, it should just check if the user exists and else fallback to a login page for manual login. I currently started to write an own middleware based on the WindowsAuthenticate but with the needs for the project.

[stevebauman]

No overrides are needed, you just need to change your sync_attributes configuration. It's set up for the stock Laravel migration.

[rogatec]

Can I prevent (by configuration), that it will not automatically tries to save the model into the database?

[stevebauman]

Unfortunately no, right now the point of the package is to synchronize AD users to your local apps database.

This is in the works though.