We’re having trouble with Active Directory on our gateways. When logging in it can sometimes take over 1 minute. Based on the below logs and wireshark screenshot it seems to be an issue in Ignition, i.e. the network and AD server seem fine.
These were captured using the identity provider test login function. The IdP is backed by an AD user source.
As shown in the images, the login appears to be almost instant, followed by a large period of apparent inactivity.
This is affecting most of our gateways, although it is rather inconsistent, i.e. some gateways might be showing this issue at one time, but at another time it might be a different set of gateways.
Is anyone able to provide any insights into what might be going wrong or what else I could do to troubleshoot this?
This is with Ignition 8.1.14
@Louis_Whitburn it sounds like when you log in the lookup is scanning your entire AD Directory. You need to define filters so that the look up is only against certain subtrees in AD. Look at advanced properties for “LDAP Search Properties” in Security / User sources / “AD name”. It will look like this…
There are other settings I only showed a few.
Role Search Filter property states that if left blank the entire AD Directory will be searched.
I bet yours is blank
Thanks for your response. I’ve attached our current configuration below
Based on that I don’t think it would be a problem. I even tried removing the “Role Search Base” filter and it took the same amount of time (42 seconds with the filter, 43 seconds without - it seems to be a little faster today). With the filter in place 44 users and 229 roles are found, without the filter it is 44 users and 1610 roles. Does this seem like enough to cause that sort of delay when logging in - even with the filter?
I would also change your User Search Filter and User List Filter to this:
User Search List
User List Filter
We always include this "!(userAccountControl:1.2.840.113522.214.171.1243:=2) " which means return non disabled accounts.
I tried that and it had no affect on login time. After some more searching I found this article: LDAP logins are slow or timing out which said disabling LDAP referrals can considerably improve LDAP login times.
After disabling this in Ignition (below image), the problem seems to be resolved.
I’m still curious as to why referrals slow down the login process but it’s resolved for now.
Thanks again for your assistance.
I am trying to set Referral to Ignore but I am using Ignition 7.9. that does not seem to have a Referral field to set to Ignore. Is there a way to do this in 7.9?
There is nothing set in the advanced properties. All the groups that are related to the logins are located in the Production Folder only. Is there a way with the User Search Filter to make it such that Ignition will only look there? Any other ideas to speed up AD login for a 7.9 Gateway?
I do have the specific names of the groups as well within the folder that are what is related to Ignition logins if that is also something that can be used.
I’m no expert but I narrowed down as follows on an Ignition / AD hybrid setup:
- Turn on Show Advanced Properties.
- Change the
User Listing Base setting to
You may find it helpful to download ADExplorer from Microsoft. Log in and if you navigate down to Production the path will be shown above the navigation tree.
Appreciated, I made a new post here since mine is specific to 7.9 if you’d like to post there - Slow AD Login for 7.9 Gateway?
We had a similar issue on 8.1, and setting LDAP Referrals to "Ignore" also fixed it.
In our environment, we had two DCs that were inaccessible to the Ignition Server (due to being on the Business side), but our other two DCs were responding with referrals before the request, causing Ignition to contact those inaccessible DCs and time out.
Interestingly, we only saw (and were able to replicate) this issue on Windows Server 2022, but not Windows Server 2016.
@Jason_Dornish I used the same Ignore referral but ended up with thousands of errors in the logs. I was able to resolve a similar issue by using port 3268 instead of port 389 to allow the LDAP queries to go against the Global Configuration instead of just the local domain and was able to address this.