Community Summit Europe | March 9-12, 2020 | Barcelona, Spain Register today
New to AX 2012 and trying to lock down security. I noted that there are 4 generic users with the Sys Admin role: Admin, BCProxyU, Dynamic1 and wfexc. Are these built-in users to support future enhancements/hot fixes, etc?
I don't want to remove anything, but need to confirm security.
The Admin is a built-in roll. The BCProxyU account is most likely running your AOS Service.I suspect the wfexc is from a third party app that you're running, possibly used on some server. The Dynamics1 may be left over from a previous upgrade.
Check the login history for to see if the accounts are being used to access AX via the client. I would disable the Dynamics1 & wfexc and see what happens.I use the following T-SQL query to monitor who is a Sys Admin and if they are enabled or not.
SELECT UI.ENABLE as Enabled, ' ' as ' ', UI.name as 'System Admin' FROM AX2012.dbo.SECURITYUSERROLe SUR join AX2012_model.dbo.SECURITYROLE SR on SUR.SECURITYROLE = SR.RECID join AX2012_Prod.dbo.userinfo UI on SUR.USER_ = UI.id WHERE AOTNAMe = '-SYSADMIN-' order by ui.name
------------------------------Mike FechterLead Business Systems AnalystIIMAKAmherst NY
------------------------------Margaret TrisselRogers Memorial HospitalOconomowoc WI------------------------------
Thanks for sharing the SQL . I ran the query in our environment and the results did not match with what I see through client. what could be the reason?
SELECT UI.ENABLE as Enabled, ' ' as ' ', UI.name as 'System Admin' FROM IIMAK_AX2012_R2_Prod.dbo.SECURITYUSERROLe SUR join IIMAK_AX2012_R2_Prod_model.dbo.SECURITYROLE SR on SUR.SECURITYROLE = SR.RECID join IIMAK_AX2012_R2_Prod.dbo.userinfo UI on SUR.USER_ = UI.id WHERE AOTNAMe = '-SYSADMIN-' order by ui.name
We are on AX2012 R3 CU8. The query is based on the AOTNAME field = '-SYSADMIN-', possibly yours is different.
The query should give you the same results as going to System Administration -> Setup -> Security -> Security Role and selecting System Administrator. Then look in the "Users with selected role" area.
Admin is the only inbuilt sys admin in Dynamics AX. BCProxyU sounds like the account you have created for the Busines Connector and should not have an account in AX. The others I have no idea why you have them.
You might want to differentiate between roles (users are assigned to roles) and users. From a admin perspective there are at least two roles with admin functions - system administrator and security administrator. I have not toyed with the security administrator function and am not sure what it provides above and beyond the system admin role. I do know we had to use that role for some users and the management reporter functionality. I am thinking a sys admin does not need security admin.
Security Administer is the admin role for management reporter and enables that user to maintain security settings in MR.
Before you disable any of those accounts you should check your batch jobs to find out if any jobs were set up under those accounts. In the past batch jobs set up under a user account have stopped working when the user is inactivated. This is a good reason to set up organization wide jobs to execute under a sysadmin account that will never be disabled.
Thanks everyone...Scott, you had that one right. Our consultants were directed to back out of their Admin access and change their roles, resulting in some batch jobs suddenly not running any longer!
Sysadmin is only for people managing the environment and not for running business processes. Everyone else should be assigned the roles they need to do their job.
Determine what roles/duties/privilleges are required for the processes that you are running in batch and assign them to the user who run do them.
If you've found this thread useful, dive deeper into User Group community content by role