09-29-2011 07:13 AM
SAS 9.2 on Windows with Active Directory Authentication
I've changed some permissions on library objects. The permissions look OK for my login, but I would like to test how they would look for someone else on my team.
I created a temporary internal ID for his account, refreshed the spawner, and started EG. I can connect to the MDS as him, but can't start the Workspace Server. Note: I can, however, RMB on the WSS and select libraries. Is this sufficient to test the security?
The Object Spawner error log is:
2011-09-29T20:01:24,507 ERROR  xxxxxxxx@saspw - No host credentials exist to start this server. Either the client needs to send in host credentials, or credentials need to be specified for the server.
OK, that makes sense.
I also tried saving a password in the user object, hoping it would bypass the AD authentication. OK, I didn't really think it would work, just telling you what I did.
Is there a way I can impersonate a user and spawn a WSS?
09-29-2011 10:52 AM
In SAS 9.2 and 9.3 as an administrator you can add an internal account for a normal user and set the password to something you know to be able to login to the SAS metadata server and impersonate them for testing metadata access controls (whilst they continue to use their normal host/AD account). The internal account added by the administrator, being internal to SAS, is not known to the operating system and so cannot be used to launch operating system processes as required for a standard workspace server. The internal account can be used to access a stored process server or pooled workspace server since they are launched in the operating system using a shared credential (like sassrv) and not the requesting users.
In order to get access to a standard workspace server using an internal account you have a couple of options:
1) convert the standard workspace server to SAS token authentication so it uses a shared credential to launch the operating system process instead of the requesting users. There are ramifications to this and so it needs to be thought about carefully first. I'd say it's probably too big a change just for temporary impersonation of a user.
2) store credentials for a valid operating system account (in the appropriate authentication domain) in metadata somewhere in the identity hierarchy for the user being impersonated. This could be on the user account for the user being impersonated or one of the groups they are a member of. There may even be the possibility the user has stored their credentials in metadata anyway. These stored credentials will be fetched for the (impersonated) user from metadata when required.
Another method for impersonating a user is to use the only method we had available in SAS 9.1.3 (prior to internal accounts). Add a second standard operting system account's userid to the accounts tab for the user to be impersonated. This could be your own userid for example (or maybe even sasdemo if it still exists, is not locked and you know the password). Before you add a 2nd user id it needs to be removed from any existing identity. I normally just add an x suffix to the userid on the existing identity rather than removing it. Watch out for the fact that you can't modify the login that was used to login to the SAS Management Console. So in SAS 9.2 I would use my personal unrestricted internal admin identity/account (Paul Admin: PaulAdmin@saspw) as the identity to make the changes and my normal day to day identity / operating system account (Paul: domain\paul) as the proxy account for impersonation. Logged into SAS MC using PaulAdmin@saspw, I would remove domain\paul from the Paul identity and then add domain\paul to to the accounts tab for the user to be impersonated (e.g. Bob). I could then log into a SAS client app using my domain\paul user id and password to be impersonated in metadata as Bob. When I access a standard workspace server the operating system process will be launched using my cached credentials for domain\paul. All file system access will be done as domain\paul (not Bob)
BTW whilst this technique allows for the impersonation of a SAS identity for the purposes of testing metadata access controls it cannot normally be used for the impersonatation of an operating system identity for the purposes of testing file system access controls. This is because you don't have the ability to launch operating system processes as that user (unless you know their password or they have it stored in metadata).
09-29-2011 04:01 PM
in 9.2 + Rather than impersonating you can (as an unrestricted account) look at explore authorisations on the objects Authorisation Tab, advanced button.
You can see the effective permission of a group or defined user, similar to Effective permisison tab on the Windows OS.