User Management Component with Multiple Internal Profiles

Hey guys,

I think there may be a bug with the user management component when there are multiple internal user/role profiles present. When I add the user management component and put the name of the profile in the “User Profile” setting field sometimes it displays usernames and roles from a different profile. Most of the time it shows the correct information but never lets me add a new user for some reason. I can add roles but it will not allow me to add any users, the add button is grayed out.

If I change the user profile to Default then the component works fine. From what I can tell from querying the internal database the authentication profile is in place and it looks like all of the correct information is there… This is in the beta 5 release, FYI.


It sure looks like you have it set to use an Active Directory / Internal hybrid profile, not an Internal profile.

You cannot add users to any of the active directory profiles. You can only assign roles/contact info etc to the users that are there. The users come from active directory - they are listed automatically. I think it is this part of your profile that isn’t set up correctly - that’s where we need to start troubleshooting.

Well that doesn’t make any sense… I thought the whole point of the Active Directory/Internal hybrid was to only authenticate against Active Directory and do user/role management in Ignition?

I currently have a AD/Internal hybrid setup in 7.5 and I can manage users and roles in Ignition, just not passwords. Did this functionality change with 7.6 now?

It does make sense - bear with me.

The functionality did change - it got better! The idea is still totally identical, however (passwords in AD, roles in ignition). The only change is that you can skip the step of adding your AD users, because the AD portion of things gained the ability to list all of the users in your AD system.

When I add an AD/internal profile, it magically has every single AD user already defined in it (albeit with no roles assigned).

I think the user listing isn’t working for your profile. What’s your AD setup look like? Any errors in your gateway log? Maybe something like “Error finding users.” under the logger “UserSource.AD_Internal_Hybrid”? You can set that logger to debug to see it looking for users. It refreshes every 10 seconds or so.

Ok, that makes sense and now that I actually looked more closely at the settings I see what has changed. I am getting an error for invalid configuration for directory search, which may be that the default settings are not correct. I’ve sent that information off to our IT guys because I have no idea if it’s correct or what it should be. :stuck_out_tongue:

If they say that it looks OK and it’s still not working I will let you know. Thanks, now I’m much less confused!

Sure thing, let me know if they can’t figure out the settings I might be able to help.

Does this mean that i have to enter an AD account with password in the Authentication settings with 7.6? One nice thing with the actual AD Hybrid version is that i do not have to involve the companys central IT department to give me an account for Ignition or add roles for it.
If this is the case, would it be possible to use the account/password of the curently logged in user when adding users?

Another potential problem would be the filter for users. Our primary use of Ignition is currently plant locale, but there are some reporting functions used by the companys central. Even if it use a role filter to list only this sites, i would end up with a few thousand users, which might be a bit confusing, unless Ignition polls also some other fields like full name, site and department and allows sorting and filtering.

I agree, there should be some search fields on the user component. While I have a few hundred users set up in Ignition, if I have to sift through every user in Active Directory it will be a few thousand. 99% of the time I know the username of the person that I have to edit/add so a search field on username and possibly last name would be very helpful.

Yes, you’ll need to enter account info so that it can list the users. And no, it can’t use the currently logged in user, because it needs this info even when nobody is logged in.

And you should be able to use the “User List Filter” property to filter out users that are not applicable.

We can add some kind of quick search to that table, I think…

Ok, so I talked to our IT guys and showed them what the settings in Ignition are and they gave me the following information, which they say gives them a list of users with their browse tool:


I put these settings in the places where I think they go in the Ignition setup and I can’t get it to work. I’ve tried different combinations and everything I try gives this error in the Console:


These are the settings I currently have in Ignition. Can you see anything that I’m doing wrong or something obvious that needs to be changed?


Your profile doesn’t have any credentials on it. You need to fill out the “Gateway Username” and password portion of the profile.

Oh… duh… Well now I feel stupid. :blush:

OK, fixed that issue. Now I’m running into an issue that I was afraid that I was going to run into. I’m getting a size limit exceeded error.


Is this on Ignition’s end or on our Domain Controllers end?

I can confirm this problem. The limit to 1000 results is the default setting in Microsoft AD Server. Some browsers can bypass this limit by doing ‘paged’ reads, but this is not really recommended. According to our IT i’m not supposed to fetch all users from the AD, but should do a search instead.
Just for fun i tried to get a full user list with an AD client using the page mode, and that took about 2 minutes.

Hm, not really. To search subtrees in the AD i have to adjust the base path, e.g. something like 'OU=pl,OU=de,OU=xxx,DC=itc,DC=global,DC=xxxto get users for one specific site, but i don’t see a way to change this property dynamically in the User management component.

I found this article about how implementing paging in the application is a better option than playing with the MaxPageSize options in Active Directory. This might be something to think about, I doubt our IT department is going to want to increase this size and I’m sure most IT departments will resist to this as well.

Hmm, interesting. Two ideas:

  1. Limiting your query to only searching a smaller subtree. (as suggested above)
  2. Tag users that should use the Ignition system with a property, and filter for that in the user list filter?

[quote]1. Limiting your query to only searching a smaller subtree. (as suggested above)
2. Tag users that should use the Ignition system with a property, and filter for that in the user list filter?[/quote]

Hi Carl, This will still be an issue for me. For #1, it depends on how well the IT group has setup AD, at the last three places I worked it is a mess and there is no easy way to get to a smaller subtree and not be missing users. For #2, I do not have any access rights to AD and would not be able to add properties. If I go to IT with this request it would take a helpdesk ticket to be routed to our main facility and an admin to update a users account. This can take days, rather than seconds directly in ignition.

I like where you are headed with AD, but I would really like Ignition to remain independent from IT operations and simply poll for data that is there in its current state.

The AD/DB hybrid now has an option to skip asking AD for the whole list of users. You can then define them in the database.