Snipe-it: Ability to run snipeit:ldap-sync and specify a custom OU

[hh-trj]

I would like to automatically import our users along with their locations periodically via cron. Our users are currently in multiple OUs, separated by office location. I might be missing something obvious, but I'm not seeing a way to do this currently (in v4b6).

What do you think about an interface like this:

php artisan snipeit:ldap-sync --location-id=1 --ou="OU=Chicago,OU=Employees,DC=contoso,DC=com"
php artisan snipeit:ldap-sync --location-id=2 --ou="OU=New York,OU=Employees,DC=contoso,DC=com"

I'd be happy to write the PR. Off-hand it looks like modifying Ldap::findLdapUsers() to accept an optional $ou argument, and then modifying LdapSync.php to use the optional argument if it is given during the call to Ldap::findLdapUsers().

[richardhofman]

If LDAP sync is enabled in the configuration, there should be a "Location OU" field that you can specify for each location. When you do an LDAP sync, either through the UI or via snipeit:ldap-sync, it should automatically assign users in the location's OU to that location. Is that not visible in v4b6?

[hh-trj]

If I go to the People menu, and then click the "LDAP Sync" button there, I can specify a location (but I see no "Location OU" field). That will just sync ALL of my users and set their location to the one location I select. I want users to be put into a location based on the OU that they are in in LDAP.

If there is supposed to be a location OU option in the LDAP configuration, that doesn't appear to be there.

[richardhofman]

Yep, I meant in the Location edit screen. So if you actually edit a location, you’ll be able to specify an OU that corresponds to that location. If you have a look in LdapSync.php you’ll see something like:

foreach ($ldap_ou_locations as $ldap_loc)
{
    $location_users = Ldap::findLdapUsers($ldap_loc->ldap_ou);
    $usernames = array();
    for ($i = 0; $i < $location_users["count"]; $i++) {
        $location_users[$i]["ldap_location_override"] = true;
        $location_users[$i]["location_id"] = $ldap_loc->id;
        $usernames[] = $location_users[$i][$ldap_result_username][0];
    }
    ...
}

This will grab each location that has an OU set, and override every user within that OU with said location.

[hh-trj]

@richardhofman6

Brilliant, thanks! I completely missed that option on the Locations page. I didn't realize LDAP was becoming more integrated into various parts of Snipe-IT.

It worked, but it did miss a few special cases.

I have my New York users under something like OU=New York,OU=Employees,DC=contoso,DC=com but I do have an OU underneath that for some special users who need their own OU for a few different reasons. For example OU=Special Users,OU=New York,OU=Employees,DC=contoso,DC=com. It did not assign a location to those users, but I would still like it to be "New York".

Do you think this is something I should open a new issue on? It's just a minor annoyance for me, nothing major. Briefly looking at the code, it looks like it should handle this just fine, but it doesn't.

[richardhofman]

@app-reroute
No worries - glad I could help! I built the current LDAP location OU implementation and have actually been intending to fix a small bug in it, but am waiting for the release of v4, because there's so much active development happening everywhere at the moment.

As for raising a new issue, I would, just for the sake of being able to track the change that's needed. I will have a look at my workplace's installation, as we do have a similar hierarchy to what you describe, and I'm fairly sure everyone in the sub-OUs is syncing across fine. Could it be a permissions issue on that Special Users OU (i.e. the Snipe IT bind account doesn't have privileges to enumerate objects in that OU)?

[hh-trj]

@richardhofman6
No, there's no additional security on the sub-OU. Permissions are all inherited from higher up. We have two sub-OUs and both are exhibiting the problem. I'm curious if it's working in your environment when you have an opportunity to test.

[snipe]

@richardhofman6 v4 was released on friday btw :)

[richardhofman]

@snipe Thanks! I saw that just after I posted my previous comment. I updated our install and everyone’s liking it so far!

@app-reroute I’m just about to run a manual sync with a test OU and will get back to you.

[richardhofman]

Aha! I think I've figured this one out @app-reroute. The process for sorting users into OU-based locations goes like:

1. Get all users (call this list G)
2. Get all locations with an OU specified (call this list L)
3. For each location (L_i) in L, get all users in L_i's OU, and set their location to L_i.
4. Remove users added to any location based on OU, from G.
5. Add all remaining users in G to the globally specified/default location.

The problem I can see, is that in step 3, the locations aren't processed in any particular order, so suppose you have an OU structure with location mappings like:

+ Parent OU (Loc1)
|
+------ Child OU1 (Loc2)
+------ Child OU2 (Loc3)

If a user is in OU=Child OU2,OU=Parent OU,DC=example,DC=com, then the sync process will find that user to be in both Parent OU, and Child OU2. Therefore, if Loc2 is processed first, then the user's location will be overwritten with Loc1 when it is later processed. So the symptoms will be seen depending on the order in which the locations are processed.

Unfortunately, restricting the depth of the search (i.e. "only pick users with Parent OU as being part of Loc1") doesn't work, because there may be sub-OUs that shouldn't be assigned a separate location. Somehow we're going to have to evaluate the depth of the OU, and prioritise the location with the deepest OU in the LDAP DIT.

I'll look into this and update.

[richardhofman]

Pretty sure #4181 fixes the issue you're seeing. It definitely synced the sub-OU locations in my directory perfectly after this change (and previously I did have a demonstrable case where it wasn't syncing properly). Also confirmed (via some debug code that I've left out in the PR) that the sorting method I'm using works.

[jenni-lifts]

Does LDAP sync for locations only work if the users are in separate OUs? Currently our OUs are separated by contactors, interns, and staff, but may be in different locations (remote and/or 3 different offices). We don't separate OUs by location, just by type.

[danharner1]

How would I get this to work. I have a parent ou of Employees, and then child OU's of locations. If one one location i do OU=location A,OU=Employees,DC=domain,DC=com it sets everyone under the parent OU and the Child OU to that location.

[danharner1]

Or how can I pull the location of each user from the location set in AD in the users attributes?