Morning folks. Looking for a little more info on setting up the AD Internal Hybrid User Source.
If I'm understanding it correctly, I should create the roles I need for my project (there are three - Admin, Chemist, Engineer) on the gateway, and the create the users on the gateway and assign them to the roles (since I wouldn't need the entire user list from the AD server - just a specific few individuals)
When I create the users, I would use the LDAP username and that would be the common user name that ties the user to the authentication.
Temporarily for testing, I gave each of those users a basic password and that all works fine.
Next I would configure AD Internal Hybrid per the user guide. And the way it would work is when the user signs on with his LDAP username and password, Ignition will authenticate the credentials with the AD server. If it's all OK, Ignition would then look internally and see which role that user name gets assigned. Am I correct so far?
If so - then I think I'm good, although I am a little concerned that once I start using the AD Server, if something isn't working will I be locked out of my gateway and unable to reverse it or turn AD off since the Ignition administrative account is now tied to AD (or maybe it's not)??
Any insight would be helpful - thanks all!
Yes, you would need to include an Administrator role in your user/role mapping IF you use that same user source for your gateway authentication. (Projects each can have their own auth, separate from the gateway.)
If you want unified auth, consider keeping the default auth profile for emergencies and setting it as a "soft failover" in the hybrid user source.
1 Like
It's a bit easier than that.
-
Use the Ignition default internal user source for your administrator login. This is most important for access if you mess up the AD Internal Hybrid configuration for any reason.
-
Use the Ignition default internal user source for contractors or support that aren't on your AD system.
-
Create the necessary roles and assign them to the miscellaneious users. The administrator account should automatically have full permissions.
-
Configure the hybrid with soft failover to the internal.
-
Add the users and set their roles in the hybrid user source. You don't need to do it in the default internal. That means that there is no need for temporary passwords. The AD password will just work!
So to address your questions:
If I'm understanding it correctly, I should create the roles I need for my project (there are three - Admin, Chemist, Engineer) on the gateway, and the create the users on the gateway and assign them to the roles.
Yes but all in the AD Internal Hybrid.
When I create the users, I would use the LDAP username and that would be the common user name that ties the user to the authentication.
Correct.
Temporarily for testing, I gave each of those users a basic password and that all works fine.
Not correct. Enter any old rubbish into the password field. AD will look for the real AD password.
Next I would configure AD Internal Hybrid per the user guide. And the way it would work is when the user signs on with his LDAP username and password, Ignition will authenticate the credentials with the AD server.
Correct so far.
If it's all OK, Ignition would then look internally and see which role that user name gets assigned.
Yes, but it's looking for the roles in the Hybrid - not in the default.
... although I am a little concerned that once I start using the AD Server, if something isn't working will I be locked out of my gateway and unable to reverse it or turn AD off since the Ignition administrative account is now tied to AD (or maybe it's not)?
That's why having the soft failover to the internal default administrator account is important.
You can consider using the Perspective User Management tool available on the Ignition Exchange. You can build it into any application or create a standalone. It will make editing users much simpler.
2 Likes
Thank you both! That cleared a lot up for me. This is the last item to configure for my project - going live next week.
Really appreciate the help!
Hi guys,
I'm the Admin for my company's Ignition system, and I'm trying to implement the same. But it doesn't seem to work for gateway login.
Here's the basic structure of my Identity Providers:
| Identity Provider |
Associated User Profile Name |
User Profile Type |
Is Failover Set up? |
Failover User Profile |
Failover Mode |
Is failover working for gateway login? |
| default |
default |
Internal |
Yes |
USBP-AD |
Soft |
Yes |
| system_default |
USBP-AD |
AD/Internal Hybrid |
Yes |
default |
Soft |
No |
There are distinct admins under each user profile:
- user "ukamani" under user profile "USBP AD", my primary userID
- user "su_ukamani" under user profile "default", this is my backup userID for cases when there's issues connecting to the Microsoft AD.
Issue comes when I set "System Identity Provider" property under "General Gateway Security Settings":
-
If I set "System Identity Provider" to point to "default" idP (which uses "default" user profile), I can log into the gateway using both "ukamani" and "su_ukamani". Meaning, the failover works here. Here are the logs for this:
-
If I set "System Identity Provider" to point to "system_default" idP (which uses "USBP-AD" user profile), I can log into the gateway using "ukamani" but login fails with "su_ukamani". It never performs the failover to "default" user profile. Here are the logs for this:
Any help would be appreciated!
Circular configuration. Don't have the default provider do any fail over. It should be the last resort in a chain of soft failovers.
1 Like
That's exactly my aim. But it isn't work in my case. My "USBP-AD" isn't failing over to my "default", so I'm having to resort to going the other way round.
And this issue is only happening for gateway page login, it works both ways on Vision Clients.
Apologies, Correction: This issue is happening for both gateway page login and Vision Clients. On projects that point to "default" user source, are able to failover to "USBP-AD", but on projects that point to "USBP-AD" user source, are not able to failover to "default".
Hi Guys,
So setup all went well and I believe I'm connected correctly to the end user's Ad system, but we're not authenticating. (When working on my dev system, I didn't even get the option to add users because I had no DC to connect to, but once on the customer's system after entering the DC and userinfo, I did get the option to add users)
I'm pretty sure we're good with the domain controller host (I can ping it) but the end user says its not the Primary DC and we shouldn't need the PDC to do what we're doing (the PDC which sits behind a firewall and would require some configuration if we really need this to be the PDC). I don't know enough to question that.
I did some other forum searching and saw some articles about needing a certificate maybe? But my thought was if that was a required step would it not just be part of the user docs for setting up AD and maybe that was an older version or something else.
I did try both port 389 with SSL not checked and port 636 with SSL checked to no difference. I don't see a lot of troubleshooting options as there's nothing in the logs about authentication.
Any thoughts?
Can you see any users if you click manage users?
Hi there - yes, but that's because I added them manually - we only have half a dozen folks who need the Ignition system so we are managing the users/roles on the gateway.
But I suppose as a test I could let it query AD for all the users to see if it generate the user list. Would all the users disappear once I switch it back or would I need to individually delete them all?
I think they will all disappear... TBH I've not done that. Typically we just set it to import the users.
Do you have this checked?
And do you have the User Listing Base, User List Filter, and User Search Filter configured?
When you say you aren't authenticating, how do you know? Errors or just not getting a security group?
I don't have that checked because I added the users manually. The filters are all set at their default settings.
Do you have the listing base set correctly? That is how AD/LDAP knows to properly start looking for accounts.
Also, see this for how to test querying AD servers: https://support.kemptechnologies.com/hc/en-us/articles/204990569--How-to-troubleshoot-LDAP-Authentication-issues-using-ldp-exe
You can use that to test your parameters configured in Ignition to make sure that you have things setup correctly.
I've lost track of what the problem is at the moment but I found Microsoft's AD Explorer very useful for understanding the structure and checking connections, etc. It's free and I was able to install it on a pretty well locked down company laptop.
1 Like
Thanks that may be useful to troubleshoot with. To answer your previous question, when trying to log in, it right away goes to "Login Failed - Please Try Again"
Listing base is blank, which according to the field means it will search everything
Yeah, then there is probably a configuration wrong in connecting to the LDAP server.
I assume that this is Window Server? If so what version? And do you know for 100% that there aren't any firewalls between you and the LPAD server you have configured?
SO I went ahead and checked the box to get all the users and that works - I now see all the AD users when I click on "manage users". So connectivity is definitely there. And I can see my user id in that list. But I cannot log into the gateway or perspective using my credentials. So the authentication part of the equation still is in question.
So... now you need to get the IDP working properly. That is a separate but related item from the User Source.
Check the Identity Providers on the gateway. Did you create an Identity Provider that references your new User Source Profile?
Oh snap! Facepalm....
No I only have the default IDP which points to the default User Source. I didn't even think about that.
Do I point the default IDP to the AD/Hybrid user source or do I create a new IDP that points to the AD/Hybrid and leave the default to point to the default in case of failover of the User Source from AD to Default?
I would create a new one based on your working user source. And then configure and test as needed.
Make sure once you have that configured and working, that you assign that the project etc..
