LDAP active status not matching

[jelockwood]

Expected Behavior (or desired behavior if a feature request)

I get the impression SnipeIT is supposed to be able to use an LDAP field defined as the 'LDAP Active Flag' to check if an LDAP account is active or not and should then set the status of the matching account in SnipeIT to the same status.
I am using FreeIPA as the LDAP server and I am able to successfully bind to it, to sync accounts from it and to use those to login to SnipeIT. What is not working is that all accounts are synced in to SnipeIT as disabled. I have defined the 'LDAP Active Flag' as being nsAccountLock which is the LDAP field FreeIPA uses for this purpose.
The following command works via the command line to find disabled accounts
ldapsearch -LLL -Y GSSAPI -h ipa.example.com -b cn=users,cn=accounts,dc=example,dc=com "(nsaccountlock=TRUE)" uid
The following command works via the command line to find enabled accounts
ldapsearch -LLL -Y GSSAPI -h ipa.example.com -b cn=users,cn=accounts,dc=examplei,dc=com '(!(nsaccountlock=TRUE))' uid

I have tried entries in the 'LDAP Active Flag' box of
(empty i.e. nothing in the box)
nsAccountLock
!(nsAccountLock=true)
(!(nsAccountLock=tue))

But none of these work. Every time a sync is done all accounts end up being listed in SnipeIT as disabled i.e. not activated.

I can say that whilst disabled accounts in LDAP i.e. in FreeIPA do have a value set for nsAccountLock i.e. nsAccountLock=true the majority of enabled accounts have no value set at all so it is not that they are nsAccountLock=false they are empty values which makes them more like nsAccountLock=

I can define an LDAP filter as &(cn=*)(!(nsaccountlock=TRUE)) and this only imports i.e. syncs active users only but they are still all marked as inactive.

So we need more flexibility over how the LDAP Active Flag is used. It seems it is looking specifically for nsAccountLock=false (or whatever field name you specify).
(what you expect to happen goes here)
I expect to be able to define an LDAP Active Flag that will work and for it to set the matching SnipeIT account status to active or not as appropriate.

Actual Behavior

Accounts always end up marked as inactive, even if you edit an account to mark it active a subsequent LDAP sync change it back to inactive.
(what actually happens goes here)

---

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

---

Provide answers to these questions:

• Is this a fresh install or an upgrade? Fresh install
• Version of Snipe-IT you're running v4.1.11-pre build 3307 (gf06852f)
• Version of PHP you're running
  PHP 7.0.25-0ubuntu0.16.04.1 (cli) ( NTS )
  Copyright (c) 1997-2017 The PHP Group
  Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
  with Zend OPcache v7.0.25-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies
• Version of MySQL/MariaDB you're running
  mysql Ver 15.1 Distrib 10.1.31-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
• What OS and web server you're running Snipe-IT on
  Ubuntu 16.04
  Server version: Apache/2.4.18 (Ubuntu)
  Server built: 2017-09-18T15:09:02
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)
  install.sh
• WITH DEBUG TURNED ON, if you're getting an error in your browser, include that error
• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error
  users aka people
• If a stacktrace is provided in the error, include that too.
• Any errors that appear in your browser's error console.
• Confirm whether the error is reproducible on the demo: https://snipeitapp.com/demo.
• Include any additional information you can find in storage/logs and your webserver's logs.
• Include what you've done so far in the installation, and if you got any error messages along the way.
• Indicate whether or not you've manually edited any data directly in the database
  No

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

https://snipe-it.readme.io/docs/getting-help

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jelockwood]

Update,

If you via FreeIPA explicitly disable an account and re-enable it then

ldapsearch -LLL -Y GSSAPI -h ipa.example.com -b cn=users,cn=accounts,dc=example,dc=com "(nsaccountlock=FALSE)" uid

now works for that account, in other words this explicitly sets a false value. However despite this the account still syncs in to SnipeIT as disabled. :(

Since all accounts keep getting disabled this is a complete road-block issue. :(

[snipe]

This is technically a duplicate of #4998, but since this issue has more information, I'll see this one open and close the other.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

[jelockwood]

@snipe This is a comment to keep this live. This issue is still broken in the current version.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

[jelockwood]

@snipe

Any likelihood this bug is going to be fixed? Do you need more information?

[steineracedo]

It's happening the same to me when I sync users from my LDAP server. All accounts keep getting disabled, also if I enable by hand an account, when it syncs back it overrides this action and disables this user again

[steineracedo]

I had to change the LdapSync.php file:
Line 171
$item['activated'] = 0; => $item['activated'] = 1;

My OpenLDAP implementation does not have a flag for active and deactivated accounts, we just move users from OU to one with disabled users. This script is expecting the UserAccountControl flag that is not present in our deployment. I think this is very restrictive to some specific LDAP implementations, maybe should be reviewed.

Cheers

[jelockwood]

@steineracedo
Thanks for that suggestion.

My own LDAP server is FreeIPA and does support an active flag. What is so annoying is that I can use this flag in SnipeIt as a filter for importing user accounts and it correctly only imports active accounts. It then unfortunately marks them all as inactive!

I use the LDAP Filter set as -

&(cn=*)(!(nsaccountlock=TRUE))

This filters the import to only import active accounts, as might be obvious the LDAP field being used as the active flag is nsaccountlock

[steineracedo]

@jelockwood the activated status seems to be modified only by the LDAP Active Flag

Above is the piece of code of the LdapSync.php and (I'm not a Laravel or PHP expert) but AFAIK is trying to modify the "activated" status based on the UserAccountControl flag that you don't have in your FreeIPA and neither do I in our OpenLDAP server

This implementation seems to be more AD oriented:
https://support.microsoft.com/en-gb/help/305144/how-to-use-the-useraccountcontrol-flags-to-manipulate-user-account-pro

In conclusion, no matter what filter you use this won't change the activated status

@snipe can you please confirm this?

[steineracedo]

btw.. in the image above what I did was to change the else condition from activated = 0 to activated = 1.. is not the best approach but it works for me... I'm syncing users with LDAP only to be able to assign assets but the auth actually is through SAML and I assign/remove SnipeIT access to users within our IdP

[Jhamende]

I'm using an IBM Domino server as LDAP server. And we don't really us an active flag there.
In Snipe IT i'm already looking for all active users on my server. When I put the same filter in active flag all my users are still deactivated, even my admin account.
at the end I also had to modify LdapSync.php Line 171 (Thanks to steineracedo ).

[pgassmann]

@snipe The default behaviour should be to keep the current activation status when the "LDAP Active Flag" is not set. I would like to manually activate some users and manage this state in snipe-it.

if the user is no longer present in ldap, then the sync should deactivate the login.

Another desirable option would be to allow login to a admin group, but not to all.

[jwhulette]

@snipe Is this still an issue? I believe your fix on Aug 27 solved the issue.
Although the LDAP Active Flag setting should be changed a radio buttons with Activate users on import Yes / No
I think it makes it more clearer to what the settings does.
Thoughts?

[vogtmh]

The LDAP import deactivates a lot of our users on every run. We're using MS Active Directory, so there should be some kind of active flag, but I haven't found out how to use it. Any advice welcome!

[jwhulette]

@vogtmh The code checks the useraccountcontrol for these values '512', '544', '66048', '66080', '262656', '262688', '328192', '328224', if the user has a value that matches they are active, if not they are inactive. Your inactive users, what useraccountcontrol value do they have?

[jelockwood]

@snipe
Any news on this being progressed to a fix? This issue is now nearly a year old.
It is becoming more of an issue as we would like to expand our use of SnipeIT and users keep finding their accounts are disabled. :(

I am now running Version v4.6.7 - build 3944 (master). I have also updated to PHP 7.2.14 and php7.2-ldap

(If anything this issue is worse in v4.6.7)

[thinkl33t]

Would replacing this flag with a filter be a good option maybe? so you'd enter:

(nsaccountlock=TRUE)
for account-is-disabled

or
!(nsaccountlock=TRUE)
for account-is-not-disabled

FWIW, we have the same issue with snipe-it disabling accounts, and its blocking a wider roll-out.

[jelockwood]

@thinkl33t
I totally agree it should be a filter. However I get the impression from previous responses above that the code is currently broken no matter what you type in.

I do use a similar filter for importing accounts i.e. I only import active accounts however they then get marked inactive. :(

[thinkl33t]

OK, for clarity, here is how i think this functionality should work:

• Newly-created users are added to snipe-it and can be checked-out to automatically
• When a sync is run, all users are updated with enabled / disabled depending on if they match an 'activated' filter or not.

When a user leaves (or before their start date), they should be disabled to prevent them from logging in etc, but should still exist so their assets can be checked in and history should still exist.

snipe-it/app/Console/Commands/LdapSync.php

Line 181 in 75032de

$item['activated'] = 0;

Having dug into the code, it appears that in the non-active-directory usecase, snipe-it is using the activated flag to see if the user should be imported, not to enable / disable their account.

In my opinion this behaviour is incorrect; If a user shouldn't be imported at all they should be filtered out in the existing LDAP filter, and the contents of the activated / deactivated filter should be used to set the active / inactive flag.

[jelockwood]

@thinkl33t
I agree with everything you say. Users however with the use of this flag would be marked enabled or disabled based on the state of the nsaccountlock field in LDAP.

I would suggest that if the field in SnipeIT is left empty then SnipeIT should not mark accounts enabled/disabled automatically and instead this would be done manually per account in SnipeIT. The initial process should be that an imported account which is new should be enabled i.e. the default is enabled.

[thinkl33t]

That would work for us, as 'inactive' users wont be able to authenticate anyway, the LDAP auth will fail.

I'd probably suggest a config variable for the 'enable new ldap users by default' bit though?

[EnvistaGit]

I have a similar issue and was wondering if there is any update.
In my case syncing ldap users causes some users to get disabled even thou i do not have that LDAP flag set to match to anything.

Would this be considered a seperate issue?

[jelockwood]

@EnvistaGit
After waiting for an official fix for ages I eventually broke down and manually patched mine as per the suggested commit in the post above at #5054 (comment)

This has certainly stopped accounts being repeatedly disabled although I do not believe it truly fixes it in actually respecting the behaviour of the LDAP flag.

[s256]

Same here.
Using openldap, no active or inactive flag.
I even patched the file, same result.
Using 4.6.13.

[chelming]

Ran into this same issue today. Using openldap and couldn't get anything in the "LDAP Active Flag" to make a difference. We have an attribute for account status that is set to Active if the account is active.

I've applied 5b8cbe2 for the time being since that enables all the users we sync.