Hi I have several Windows Server 2012R2 with ASA Version: 16.0.0.2283 installed but I have one in particular where xp_cmdshell doesn't work. I have created a Service wich run with the Local system account and IT DOESN'T WORK, but if I create the Service wich run with Other Account using the user administrator (Windows Server user), IT WORKS FINE. This is a problem, because each time my customer change the administrator password, I have to change the password for the ASA service Is there any security consideration ? ///////////////////////////////////////////////////////////////////////// With a Service wich run with the Local system account : ///////////////////////////////////////////////////////////////////////// CREATE FUNCTION "dba"."f_getmac"()
RETURNS LONG VARCHAR
END ///////////////////////////////////////////////////////////////////////// In the windows session as administrator (Windows Server user) at Sybase Central I log into the Database as dba and I execute on Interactive SQL: SELECT "dba"."f_getmac"() ; the result is: NO DATA ON FILE the file c:\test\macinfo.txt is NOT created. ///////////////////////////////////////////////////////////////////////// In the same windows session as administrator (Windows Server user) if I execute at the command promt: getmac /NH /FO CSV > c:\test\macinfo.txt the file c:\test\macinfo.txt is created and the contents is OK: "DC-53-60-17-34-F5","\Device\Tcpip_{BF4E5CFB-81B6-431F-90B6-1B520099BBD1}" ///////////////////////////////////////////////////////////////////////// |
This would be a Windows security credential issue and there will not be any SQL Anywhere features available that could circumvent that aspect. Assuming getmac requires administrator priviledges (and not something not so all-encompassing) . . . One possible approach would be to create a local account that is a member of your administrators group, that has a fixed unchanging password that never expires. If you can also prevent logins for that account and still use it for this service, then that would be more like the way Unix daemons (and set-user/set-group permission) were often set up. But that is pretty old-school and may not work or may not pass your local policies. If you can identify a more limited set of permissions for getmac then you may be able to grant those to the SYSTEM account directly [as is sometimes required for file system permissions]. For example if getmac just accesses the registry you may be able to grant SYSTEM permissions to the specific. You might want to use the Sysinternals "Process Monitor" utility to compare where getmac differs from a working trace (in the foreground) to see if you can incrementally add permissions. Another alternative might be to capture this information once (or occasionally) from a foreground application into a file and just reading that. This might be an additional required step of your installation. Hopefully something in the above will help but these are just suggestions and not recommendations. If this hasn't I would check on other Windows-focussed forums to see if there are better 'best practices' for this. |