Repository navigation
Snipe-IT Version8.3.5 - build 20406 (master) How can we help?Hello! I have set up Snipe with LDAP sync to sync all the users in our org - however I don't seem to be able to both have an LDAP sync enabled and also use the local-to-snipe passwords. I only want a subset of our IT dept to be able to login, and have the LDAP sync mainly to keep an up to date list of users on snipe to be able to assign assets and devices to them, rather than using LDAP as a logon mechanism. I can manually create the user, and then set them a password before the LDAP sync automatically kicks in and figures them out as a user on the LDAP server, but it means they then can't reset their password if they forget it, and as our LDAP server does not have passwords (it is just a user directory, rather than an auth method), there isn't really much recourse other than to delete their account and set a new password upon manual recreation. I have AD Server unticked as well as hashed passwords unticked but this doesn't seem to have made much difference. It seems like Snipe presumes if you are using LDAP to sync data, that it will also presume your LDAP server you are syncing to also has an authentication method and passwords. Any help appreciated! Code of Conduct
|
Replies: 8 comments 2 replies
|
So how I've worked around this for years is to have LDAP enabled for login but in the SnipeIT Settings under LDAP there's LDAP Active Flag. This lets you pick a field in LDAP to use to set whether a user is allowed to login. For easiness I used "Pager" as the attribute name is just pager but Fax might be another option which would be facsimileTelephoneNumber. You set this to 0 on all the accounts you don't want to login and 1 on all the IT people who can then login with their LDAP account. |
Thanks for the response! I was really curious as to whether there is a way of setting users to use the SnipeIT native login instead - the LDAP server I am syncing to doesn't have a login mechanism - it's purely just a user directory so there isn't a password for it to check against! The only workaround I have found is to delete the user's account, and manually re-add one before the LDAP sync kicks off again, which I have only set to run once a day so gives me some time. This means if a user forgets their password, I have to delete their account and recreate it instead of them just being able to request a password reset, which doesn't seem to work if you have LDAP enabled. |
|
Yeah I see what you're saying now it's going to match them up with LDAP and then it's not going treat them as local is it. I can't see a way in my install to distinguish that. I'm guessing it's going to sync the user based off the username or the email address. Maybe another workaround could be a username that doesn't resolve e.g. a different username completely or an email alias on their mailbox which wouldn't marry up to their primary email address then it might not class them as an LDAP user and treat them as a local user. |
yeah definitely, I'm using the users issued ID that is on their work ID cards and that they use for all the other systems, as that makes the most sense - changing their ID would mean they have two accounts on Snipe though, and my automated scripts would assign their devices to the account they can't log in with, so it's a bit of a catch 22. A "LDAP Login" toggle would be a nice to have on user accounts, so Snipe knows where to direct the login to. My account is currently synced to the LDAP server, but because I set a password before I set up LDAP sync I can still sign in, and I know it isn't authenticating with LDAP when I log in, because the LDAP server i'm using doesn't have a logon mechanism! It's the same if i delete/recreate the user - so Snipe knows where to login from, but isn't exposing the choice to the user. Would be handy to have! |
|
User sync is perfectly possible without LDAP login. They are two separate systems. Although we generally recommend SCIM+SAML in that type of scenario, since SCIM gives you "just in time" user provisioning in Snipe-IT, and SAML gives you the SSO login support. |
That's our fault - we don't make that super duper clear, since in general, it's a weird thing to try to toggle and there aren't a ton of use-cases for it. We'll try to make that clearer in the UI moving forward.
Yep, that's why our users love SCIM+SSO so much. SCIM just hits our SCIM API endpoint and creates/updates users if they don't already exist, but does not provide any login mechanism. It's also a lot more "set it and forget it" than LDAP user sync can be. We don't even have a setting page for it in the settings because once you get it set up, it Just Works. If you just want user provisioning (they exist, but they cannot login), SCIM is a great solution. LDAP/AD is great, but it's fiddly as hell, since it can be kinda whatever you want it to be (which can be great, until it's not, or until you're not the one with direct control over the directory field names and/or settings), so you have to map fields specifically if you didn't use the defaults, etc. SCIM's spec is pretty clear, so we've seen great success from our users once they get that set up. Here are our SCIM docs btw - https://snipe-it.readme.io/docs/scim One thing to note - and it's mentioned in those docs I think - if your username structure differs from your SCIM provider (assuming you have one), you will create duplicate users unless you rectify that before setting up the SCIM integration.
|


If I'm reading this correctly, I think you'd just need to use the active flag and then bulk edit users to "disallow password management" via bulk editing.
This effectively toggles the
ldap_enabledflag in the user table, since you wouldn't want an LDAP user to be able to edit their password through Snipe-IT.I'm honestly a little unclear on the ask here though.