User Manager Mapping not working

[chrisnutt]

Hi All,

I've just noticed that User Manager Mapping is not working for us.

Attached is one of our conf files (with all our vital info stripped out from the first section).

Any user in the OU this applies to I check in Hornbill, there is no manager listed.

I found this thread: 

Which led me to check the regular expression in a checker which seems to return "CN=USERNAME,OU=" from the manager attribute. Is this right?

Any other ideas?

Thanks in advance!

it_conf-for-sharing-forum.json

[Conor]

Hi @chrisnutt

I am not 100% on this one but looking through my guess is that you need to set the 'GetIDFromName' to false. 

From what I can see, you are currently searching on a full name, whereas if the value you are returning is a username then that will not match. So by turning the getIDFromName value to false it will then just search on the ID, which will match the correct username.

Just tried on our AD, in ours the DSN starts like this: CN=Steven Boardman,OU=HSL Users,

So the regex against that string will return Steven Boardman. In your case though (if I understand this correctly) it is returning C.Nutt. 

So if the GetIDFromName value is true then it will search all users in your instance for C.Nutt in the Full Name field, which it will not find, and then it will try to put the ID of the record (if it did find one) into the manager field.

If you set that value to false then it will just search for the ID based on the string the regex returns, rather than the full name field. So in your case it will search for the ID of C.Nutt.

Give this a try and let us know how you get on.

Thanks

Conor

[chrisnutt]

Hi Conor,

Thanks for the reply. I've just changed GetIDFromName to false as you're right and it is my username in the start of the DSN.

It still doesn't seem to work though, unfortunately.

I've run the regular expression through an online checker and it returned as per the attached. Will that not affect the process?

I've also attached what I'm seeing on a member of my team where I would expect my name to be in the manager field just for completeness.

Chris

 

[Conor]

Hi @chrisnutt

I have had a look at the import script and it filters out the CN=, OU=, etc. so it will be left with the first group i.e. CNutt. That value is what is then used to search the rest of the users for the relevant ID, so I am pretty sure the regex is not the problem.  

If changing that value didn't work then it will be something simple, but we will need to run a couple of tests. The first thing to rule out is the data, can you update the Filter at the top of the conf file with the ID of the person in the above screenshot, so it looks something like this (but obviously replace stevenB with the ID of the person in your team): 

"Filter": "(sAMAccountName=stevenB)",

This will limit the import to just this person, and then can you also put the manager value into one of the attribute fields. So one of your attribute values will look something like this:

"Attrib8":"[manager]"

This will put the manager value into the spare field so we can see what the script is working with.

Give this a try and let me know what the value in attrib8 for that user is, and we will hopefully rule the data out as a potential problem.

Thanks

Conor

[chrisnutt]

Hi Conor,

I've done as you suggested - although I used a different field as the attrib fields are limited to 64 characters and the result is longer - and the value is as it should be (i.e. me!):

CN=CNutt,OU=IT,OU=XXXXXX,OU=XXXXXX,DC=XXXXXX,DC=XXXXXX,DC=XXXXXX,DC=XXXXXX

Chris

[Conor]

Hi @chrisnutt   

Thanks for trying that.

Can you please attach the log file that will be in the folder with the executable. Obviously it is not the data, so hopefully the log will shine some light on what is happening. The one from this afternoon may be a bit light with only the one user imported, so the one from the initial test yesterday might be best? 

Probably best to PM me the log file in case there is any sensitive info in there.

Thanks

[chrisnutt]

Thanks @conorh . Getting that info now.

Chris

[Conor]

Hi @chrisnutt

Just thinking out loud, I've been away for a long weekend so finally had a couple of seconds to think! If you tried exactly the same script twice, once straight after the other, does that work by any chance? The script creator is apparently back tomorrow so will be able to get something in there to figure out the problem, but in the meantime I was thinking that maybe it is something to do with the cache and that all the info is not there to start with.... Just a thought, but worth a quick try. As I say I will bug the creator tomorrow as soon as he sits down to try and figure this out, but if you have a second can you try and run that script twice in succession?

Thanks

Conor

[chrisnutt]

Hi Conor,

Just ran the script 3 times (one for luck) but I'm afraid it didn't work.

Chris

[Conor]

Ok, thanks for giving it a go. As I say I will chase it up tomorrow, so I will be in touch asap

Thanks

Conor

[chrisnutt]

No problem. We've got some time

[TrevorKillick]

Hi @chrisnutt

Can you ping me over one of your latest LDAP Import Tool Log Files please (trevor.killick[AT]hornbill.com) i need one to tally up with the latest instance log files to try and work out whats going on here.

Kind Regards

Trevor Killick 

[Martyn Houghton]

@chrisnutt

I just checked our LDAP import conf and we just insert the [manager] attribute directly. Looking in our AD using LDAP Explorer, our [manager] entity has just the distinguished name (DN) of the users manager and not the fully qualified AD identity of the manager.

https://msdn.microsoft.com/en-us/library/ms676859(v=vs.85).aspx

    "UserManagerMapping":{
        "Action":"Create",
        "Enabled":true,
        "Attribute":"[manager]",
        "GetIDFromName":true,
        "Regex":"CN=(.*?)(?:,[A-Z]+=|$)",
        "Reverse":true
    },

"UserProfileMapping":{
        "MiddleName":"",
        "JobDescription":"",
        "Manager":"[manager]",
        "WorkPhone":"",

Not sure if you are trying to do something different with the manager setting, but the above is working for us with XMLMC LDAP Import Utility V2.4.1.

Cheers

Martyn

[Conor]

There was a setting introduced to resolve this issue called ManagerSearchField in the import script. The latest script and the supporting information can be found here: https://github.com/hornbill/goLDAPUserImport.

The setting was introduced to allow each organisation to choose which field is searched to apply the relevant manager detail for their own AD. By default it searched on the full name, but in the above example it would need to be changed to search the ID of the users rather than the full name to put the correct user into the manager field during the import.

[chrisnutt]

Thanks @Martyn Houghton

That gets me the DN in there, but I have to disable the  manager mapping and the DN doesn't resolve to anything.

I'm going to take rebuild a conf file from the latest one and try again, just in case I've changed something somewhere down the line to cause this.

Chris

[Martyn Houghton]

@chrisnutt

Looking at your original config at the beginning of the thread, you are using [displayName] for the users name where as we use [cn]. Given the matching is using the [cn] element when matching might have an impact?

Cheers

Martyn

[chrisnutt]

Thanks, @Martyn Houghton

I changed it as you suggested as a test but it didn't work. However, as you mentioned my original config at the beginning I went back there and tried the suggestions from @conorh again on a newer version of the import tool than was available back then and it seems to have now worked! I'm not entirely sure how yet, but I don't mind at this point!

Thanks for getting stuck in to help me with this.

Chris