Snipe-it: LDAP - New User Creation Fails "ErrorException in AuthController.php"

[ITNetMan]

Expected Behavior (or desired behavior if a feature request)

When LDAP authorization is enabled, we would expect the following to be the flow of authentication:

• Bind to LDAP Server
• Lookup user on LDAP
• Check local database for user matching authenticated LDAP user
  
  
  
  • If user exists, update user info with LDAP information and login
  
  
  • If user does not exist, create user from LDAP information and login
  
  

---

Actual Behavior

• Bind to LDAP Server
• Lookup user on LDAP

• Check local database for user matching authenticated LDAP user

  • If user exists, update user info with LDAP information and login _(works if I manually create local user before attempting LDAP login)_

  - If user does not exist, system says it's about to create local user from authenticated LDAP user, but then fails with error as follows:

LOG.error: exception 'ErrorException' in AuthController.php line 157:
Message: 'Non-static method IlluminateDatabaseEloquentModel::save() should not be called statically, assuming $this from incompatible context

---

Please confirm you have done the following before posting your bug report:

• [x] I have enabled debug mode
• [x] I have read checked the Common Issues page

---

Please provide answers to these questions before posting your bug report:

• Version of Snipe-IT you're running
  Version 3.0.0-dev-3
• What OS and web server you're running Snipe-IT on?
  Windows Server 2012 on IIS 8.5
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)
  Manual installation following Version 3 install directions
• If you're getting an error in your browser, include that error
  See attached files
• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error
  Login page
• If a stacktrace is provided in the error, include that too.
  Attached
• Any errors that appear in your browser's error console.
  Attached
  stack_trace.txt
  LDAP_Error.pdf
  
  
• Confirm whether the error is reproduceable on the demo.
  Have not tried due to LDAP credentials and security reasons
• Include any additional information you can find in app/storage/logs and your webserver's logs.
  n/a
• Include what you've done so far in the installation, and if you got any error messages along the way.
  Install went great and new pre-flight is awesome!
• Indicate whether or not you've manually edited any data directly in the database
  No

[snipe]

If you can pull the latest for v3 (not v3-master - it's not been merged yet) and let me know if that woks, I'd appreciate it!

[snipe]

(Also make sure you run composer dump)

[ITNetMan]

I just tried it out and am now running Snipe-IT version v3.0.0-dev-4-4233c781a

I'm no longer getting the full error, but it also doesn't look like it's looking up in LDAP properly. The errors indicate that the login user it's not authenticating correctly against LDAP (bind user is working properly according to the LDAP Test button.

[09:04:47] LOG.debug: LDAP is enabled.

[09:04:47] LOG.debug: Local auth lookup complete

[09:04:47] LOG.debug: Binding user to LDAP.

[09:04:47] LOG.debug: Local user tech does not exist

[09:04:47] LOG.debug: User did not authenticate correctly against LDAP. No local user was created.

[09:04:47] LOG.debug: Authenticating user against database.

[09:04:47] LOG.debug: Local authentication failed.

Normally I would think this would be an LDAP filter issue, but nothing has been changed since the last time. My filter is set to &(cn=*) still and my base DN is the top of my organization. Also, my LDAP Auth query is set to samaccountname=

Anything else I should try?

[snipe]

Do you have any access to LDAP logs or anything that could give us more info?

[ITNetMan]

Attached is what I could pull from our AD Domain Controller (redacted to pull out confidential info).

"snipeldap" is the username of the binding user which is successfully binding from what it seems, but I don't see anything in regards to any failures to login. I'll try to see if I can pull anything else as well.

LDAP_Logs.txt

[ITNetMan]

After testing with another one of our applications which uses LDAP bindings, what I'm seeing is that the "Credential Validation" log shows that the end-user (who we are attempting to login as) is shown in this log as well as the workstation from which we are attempting to login from. The LDAP server then validates this user and response back with a success.

When Snipe sends the credential validation, it looks like it's trying to authenticate the LDAP bind user instead of the end-user. Also instead of the workstation name being listed, it instead shows the LDAP server instead.

I'm for sure not an LDAP expert, but in a side-by-side look at the failed Snipe and Successful other app "Credential Validation" log this is what I see. Attached is a side-by-side screenshot.

[uberbrady]

So here's my _hypothesis_ of what's going on here, based on fragmented memories I have and very jumbled beginner knowledge of AD -

The way we _used_ to log in via LDAP was:

1) We do a search, appending a search criteria of <your_username_field>=<your_username>. E.g., for a 'standard' LDAP setup, somethiing like uid=brady. For an AD setup it's probably samaccountname=brady. This search is done against the baseDN - something like ou=something,dc=example,dc=com.
2) We grab the first result
3) We call PHP's ldap_get_dn() on that result to get the formal dn for the user.

But that requires that you authenticate to LDAP first using the Admin credentials, and only _after_ that trying to re-bind using the user's credentials. So the new way is simpler -

1) We take <your username field>=<username>,<your base DN>, and the supplied password, and try to 'bind' to AD directly with that.

I suspect, if my memory serves, that in Active Directory, that's not how usernames look. I seem to remember it being just the short username. E.g. instead of that long string above - it's just <your username> - that is all.

_IF_ that is, in fact, the case, then we need to add a new "log in using _only_ username" setting (which could just as easily be called "Using Active Directory Server-style usernames") - and if that checkbox is checked, then we don't try to compose together the userid as above.

It _might_ be that, in AD, you just authenticate using samaccountname=<username>? I don't know, and I don't have an AD server handy to be able to test.

[snipe]

@ITNetMan I've pushed out a possible fix to the v3 branch, but as @uberbrady said, we don't have an AD server to test with :( If you could do a fresh pull of v3, run migrations and try that, maybe it will work? It's really challenging to try to test this blind. :(

[snipe]

(Oh, you'll also need to go into settings and check the Active Directory checkbox)

[ITNetMan]

So I've been able to go through and pull the new V3, migrate, and check the AD box in the LDAP settings. The odd thing is _(and this was probably happening before too)_ that the only time I see anything come through on my AD logs showing that Snipe-IT is checking credentials is when I do the "Test LDAP" button.

When I press the button, it shows that everything works, and I see the same logs that I had posted earlier. However, anytime I try to test with any user from the login screen, I never see anything in the AD logs at all. The Debug Bar shows the same info stating that "User did not authenticate correctly against LDAP. No local user was created.", but it almost seems from the AD logs that it's not even trying to authenticate or not getting as far as getting to the server to check credentials.

I greatly appreciate the time everyone is putting into figuring this out...especially for not having AD to test with!

[ITNetMan]

With the new "AD Checkbox", I see that in the Ldap.php function findAndBindUserLdap there are some strange things happening. It looks like the baseDN is being set there as just the username instead of using the baseDN set in the settings.

I've found that in the username if I use domainusername, it will get past that initial error and instead give me an invalid DN syntax error. This is probably because of the way AD does things a bit strangely. In order to login to AD, it needs the domain name prepended at the beginning like domainusername or the [email protected].

But then later on when you do the filter, it should just be sAMAccountName=username without the domain portions in there.

I think there's a mix of the baseDN being set to the username and the filter queries being off which then errors out before it can even try to validate credentials with the actual server...which is probably why I don't see any AD logs when I try to sign a user in via the login page.

Here's an example I was trying to compare back and forth with:
https://www.exchangecore.com/blog/how-use-ldap-active-directory-authentication-php/

[uberbrady]

Yes, that was the 'old way' that we did it, and while it did have some advantages, it also had some problems - if we can get the 'new way' working, hopefully it'll have all of the advantages, and none of the problems (we hope!).

I'm hoping to have some updated info for you to try soon.

[snipe]

@ITNetMan Can you do a fresh pull off v3 branch, run migrations, edit settings to add your AD domain, and try again?

[snipe]

(We set up an AD server to test with, and that's working for us now.)

[ITNetMan]

Yes! It looks like I'm almost there now. The authentication now does seem to be working. I see in AD audit logs that the end-user is being authenticated against the directory..

The only issue now is all the way back to my initial problem where it's authenticating against AD, but then something is failing on the "create user" process. Here's a snapshot of the debug bar now:

This debug was with a user who is not on the local database but is on AD. I assume that it should be creating the user with the attributes it found on AD. Is there any other logs for the create user process that I can pull?

I've also tested with an existing user on the local database who also exists in AD. The system will use the AD password instead of the local password which is good. It logs in and says it's updating the user, but it doesn't seem to actually update anything. I've tried to delete the email field on the local database to see if it would populate from AD, and it looks like it didn't go through. Seems probable that it is a similar to whatever reason the create user process isn't working.

Any ideas regarding these symptoms? Thanks for all the help to get us Windows/AD users up and going on v3!

[snipe]

Okay, this is great news. Usually when a user create/save doesn't work, it's because some piece of required data is missing. Can you confirm that those users all have a first name, last name, and username, and that those field mappings are correct in the LDAP settings in Snipe-IT?

[snipe]

We really appreciate your patience while we work through this, btw. We JUST rewrote how LDAP/AD authenticates so that it's a more "pure" connection, authing with just the user on login, not as the admin and then searching and doing all kinds of other business. Now, the only time the admin LDAP info is needed is on LDAP user import. Everything else relies on the user who is trying to login, which makes more sense than the way we used to have it, and also doesn't completely hoark login if your app key changes, which it used to do, since the LDAP password is encrypted on the server, and it uses that app key to decrypt it. If the app key has changed, it can't decrypt, and Very Bad Things used to happen.

[ITNetMan]

So I've gone through and verified that all my mapped fields were correct and were populated with data in the directory. When I sign in, it gives me that same sign in error showing that it couldn't create the user.

I saw in another issue here on the forums where it said to try putting the field names all in lower case.

Here's the really odd part now. When I change the "Username Field" from normal field name casing (sAMAccountName) to all lower case (samaccountname) and attempt a login, I just get a completely blank page. No debug bar...nothing.

I tested changing one field name at a time in the LDAP settings from proper casing to lower case and none of the others had this effect. Only the "Username Field" changing casing had this error. No idea what that possibly means.

Here's a screenshot of my mappings:

[ITNetMan]

And also here's a screenshot from an LDAP browser of the fields I'm using within the directory and their values:

[snipe]

Very bizarre. Here are mine (where it works)

[ITNetMan]

Got it! The user that I was attempting to login as I had previously also created as a local database user and then deleted it. It was still sitting in the "Deleted Users" area so I think some sort of conflict happened and made that blank page instead of signing in.

I went into the settings and did the "Purge Deleted" which fully deleted that user. Afterwards, I tested the sign-in and everything worked properly to create the user and populate the fields.

I did try to login again as a user who is already on the local database who I deleted a field from. I just wanted to see if it would "update" the user with the email field that was in AD. That part still didn't update, but I'm not too concerned as the main thing was the authentication and creating new users.

Thanks a ton for walking through all this troubleshooting with me!

[snipe]

HUZZAH!

Man, I"ve never been so happy to close a ticket... lol

[snipe]

(Incidentally, which field did you delete, to check if it was updating? I'll try to reproduce it locally.)

[ITNetMan]

I deleted the email field on the local database and was trying to have it pull from the LDAP/AD mail field.

[snipe]

Can you check again with a fresh pull?

[ITNetMan]

Works! Did the same test afterwards by deleting a user's email field in the local data and then just signing in via LDAP/AD. It pulled the data and updated. Thank you!