Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
Good day everyone,
Today we changed the name of a group in our Active Directory and as a consequence we locked all users relying on that group out of the system for a while until we figured out where the problem is coming from - apparently, the connection between AD & Thingworx is based on the AD Group's name rather than its unique SID. For organisations where names can change frequently, this is quite the issue - is there any way around this currently?
Kind regards,
Martin
Solved! Go to Solution.
Hi @Frowne
I think it is possible to map ThingWorx Group to AD Group by specifying attributes other than the common name.
Simply change the Group Attribute Name in AD configuration in ThingWorx.
For example:
I want to use E-mail attribute as the identifier for AD security group and never change this value
Then in ThingWorx AD configuration, set the Group Attribute Name to mail
In GroupMappings, specify the mail value of the Security Group instead of the common name.
Thanks,
You need to configure your AD to send the "group-id" as claim instead of the "display name". Then in TWX you need change the mapping to use the ids to TWX groups (in the ThingworxSSOAuthenticator).
What kind of AD are you using? AAD?
We're only synching to Azure, we're using an in-house one with Windows Domain Controller. Generally, I do believe it's set up properly from our side specifically, I'm just wondering about how to properly implement it on Thingworx' side of things.
I'm assuming you are talking about the ThingworxSSOAuthenticator's "Identity Provider Group Name"?
Yes, I was referring this section. But I assumed that you are already using this section to map your "ad group name" to twx groups. From what I understand you don't do that? So most likely I have misinterpreted your setup (I thought some Single Sign-on setup is in place).
Not exactly - we have a project with a Thingworx Directory Service which has the group mappings from the Active Directory to Thingworx Groups - the problem is that the mapping and search functionality there only lets you select the AD Groups by name so that's when everything broke once the name was changed internally
I see. I have no experience with this one. In the docs I only found
https://support.ptc.com/help/thingworx/platform/r9/en/index.html#page/ThingWorx/Help/Composer/Security/DirectoryServicesAuthentication/ActiveDirectoryGroupsDynamicLogin.html# the parameter "Group Attribute Name" which defaults to "cn" (common name) which twx will use for mapping. Not sure if you could change this to something else which identifies the group by id?
From my google search it does not seem that the AD-group contains some id https://stackoverflow.com/a/33961313
There are attributes for groups in Active Directory for groups that have unique values: objectSid, objectGUID
It would be a great improvement to configure the mapping to those attributes instead of the group name.
Indeed - and how to do that using a Thingworx DirectoryService is why I created this topic. Sadly, in the group mappings it seems like you can only add mappings via common name.
Hi @Frowne
I think it is possible to map ThingWorx Group to AD Group by specifying attributes other than the common name.
Simply change the Group Attribute Name in AD configuration in ThingWorx.
For example:
I want to use E-mail attribute as the identifier for AD security group and never change this value
Then in ThingWorx AD configuration, set the Group Attribute Name to mail
In GroupMappings, specify the mail value of the Security Group instead of the common name.
Thanks,
That's definitely a workaround but not at all what I was looking for - e-mail addresses could also feasibly change, I want to use the unique identifier, no other arbitrary properties that could be subject to change potentially.
I'm still interested in a potential solution here, but we've instead used a work-around on our end, creating a new AD group whose name is never going to change and putting the previous one inside it.
But this is still a possibly correct approach: You could also use the ObjectGUID. It never changes.