Understanding User Administration

[#1]

Did you miss the Ask the Expert session on Understanding User Administration? Not to worry, you can catch it on-demand at your leisure. I’ve attached the slides as well.

Watch the webinar

This session covers the process of authentication when logging on to a SAS^® client application, as well as when accessing data through program code or generated code through the SAS client interface.

Topics include: host authentication, Integrated Windows authentication, metadata identities, internal accounts and internal authentication, authentication to the workspace server, SAS token authentication, the role of the object spawner, authentication to third-party database servers, outbound logons, authentication domains and credential management.

 

Here’s a transcript of the Q&A segment held at the end of the session for ease of reference.

­Why is "log on as batch job" permission required for users on Windows servers?

­

For host authentication (not IWA), the log on as a batch job is needed to run SAS servers such as SAS Workspace Server. On the Windows machine that hosts the object spawner, give this privilege to the accounts under which workspace servers and stored process servers run.­

So, if users don't have "log on as batch job" permission, then is Token authentication the only alternative?

­

Yes, that is correct.

­How would we configure IWA?

­

The following link to our documentation provides step-by-step instructions for IWA authentication: How To Configure Integrated Windows Authentication

­Do we need to enable extended monitoring to see the Authentication Error stored process?

­

Yes, that is correct if you want to see the error being captured and stored in the data mart tables, and therefore have the reports available. You can always modify the logconfig.xml for the stored process server to capture the information in the log, or for that matter, any of the logconfig files for your sas servers.

­So SASSRV should have permissions to all the files the particular stored process needs?

­

­For the files/tables that are requested via the stored process code, the sassrv account does need access to the files that are requested. By default, the sassrv account is added to the sas group in a UNIX environment (via the Deployment Wizard), so for any OS files/tables you can make sure the sas group has the appropriate permissions.

If the stored process properties on where it will run are choosing to always run on the workspace server, then it is the individual user credentials that will need the appropriate permissions in the OS for the files that are accessed.

What about connection to the databases?  It uses SASSRV's database credentials?

­

If a SAS/ACCESS engine is used, then database credentials must be stored in metadata for seamless access. The SAS Spawned Servers account must access the credentials stored in metadata at server initialization. You would have an identity (a person or group) in metadata that has the appropriate credentials stored with it. Then you would add the SAS General Server group as a member to that identity. (SAS Spawned Server account sassrv is stored in logins on the Accounts tab of the SAS General Servers group.) How to Store Passwords for a Third-Party Server.

Or, if you do not want to store database credentials in metadata, you can hardcode the libname in their store process code. For example:  libname oralib oracle user=scott password=tiger path=orapath schema=schamename;

­What if you want to prompt for credentials?

­

­The easiest way is not to store passwords anywhere­.

­What is the function of "external identities" for windows? For example, when I open a user properties in SMC, I see "external identities" tab. what is this for?

­

­Each metadata user/group can be associated with an external identity, from their security provider, such as OS, AD, LDAP. SAS supplies import macros and synchronization macros that you can run to load or update your metadata identities with the accounts stored in your security provider. The value of the external identity is what is used to make sure there is a unique one-to-one comparison with what is in metadata and what is in your security database.

Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q/A, slides and recordings from other SAS Ask the Expert webinars. To subscribe, select Subscribe from the Options drop down button above the articles.

[MichelleHomes]

Thanks for an informative webinar. The slides to the presentation don't seem to be attached.

Kind Regards,

Michelle

[AnnaBrown]

Thanks Michelle, thanks for your comment! The slides are now attached. 🙂

Anna

[MichelleHomes]

Thank you Anna!

[ronan]

 Thanks for this instructive presentation. This is not an easy topic, to say the least and that was clear enough :). SAS Authentication often comes out as very specific compared to other platform-based tools which often rely more (it seems) on user directory delegation : authorisation rules are defined and managed within the directory itsef (filters based on AD Groups, for instance). Whereas SAS Metadata autorisation model is more inclusive, fully equipped and self-reliant, which is sometimes unusual to IT people not SAS aware.