Hello Dojo,
I would like to better understand the dependencies and possible difficulties with local Dataminer users in a DMS consisting of multiple agents. Through experience every now and then we run into strange user problems. A user can not login anymore on one agent while he can login on another agent. Or a user is not able to successfully change his password on initial login after a Dataminer administrator has reset his account with a new password (change at next logon). These are just examples of some phenomenon experienced on live systems. I am talking only about local users (not domain users). When created on dataminer, these users are created as local users on each of the windows servers hosting the dataminer agent.
I can imagine that a potential cause of such issues could be the local security policy (including password and account lockout policies) on each of the windows servers making up the DMS.
If on one server in the local security policy, the password complexity policy is enforced while on the other it is not
or when
on one server the max password age is different than on another I can image various user problems can occur on DataMiner or DMS level.
Am I correct to say that the password and account lockout policy for local DataMiner users fully relies on the local security policy of the underlying windows servers?
When a password on a server has expired (due to the 90 days password age policy) will the user be warned by Dataminer if he logs in / tries to login? Will he be offered to change his password? Or simply denied to login without any explanation?
Are there any guidelines or best practices for the windows security policy to avoid potential problems at dataminer level?
Thanks for sharing your feedback on this topic!
Hi Koen,
Correct, for local users, the password and account lockout policies fully rely on the underlying OS. So, you need to make sure those are consistent across the different DMAs or you might experience unexpected behavior.
If the password of the local user is expired, you should get a possibility to change your password, at least with Cube, not sure about the web apps, those might maybe not support that.
My recommendation would be to avoid local users, and try to reuse existing accounts from a domain, or, and this is the best solution, use a SAML integration with Azure AD (Entra) or OKTA or something like that. Those identity providers are the most modern and most secure way of authenticating. They typically support MFA and have lots of goodies in terms of security and protection. These accounts are the best way forward...
Bert
Thanks Bert. Understood and fully agreed.
For those deployments however that still use local users it is clear now that local security policy must be identical on all servers. A task that is sometimes overlooked …