Out analytic users need access to raw data which typically is in oracle or sql databases. They need to authentified by there ad user. The sas administrator will not update their password manually. is it possible to use either manual login by signing in to each connection and how do i set it up in the SMC??? ? I prefer that the users sign manual up every time they use an authdomain. the apllication server in an hp unix and the users are resolved into a shared workspace user - it is critical that the database know which ad user signs in. is there a smart solution?? thanks in advance.
Hi,
One of the things you mentioned is
"the ad user are translated to a shared use", and "I prefer that the users sign manual up every time they use an authdomain", and "access to raw data".
First question:
How are your users currently reading these raw data into SAS/access the raw data?
Via BASE SAS, EGuide, DI?
One the raw data is imported and data sets are created, are the data sets stored in metadata libraries?
Since you mentioned SASMC, I assume that all your users are registered in Metadata, and that your libraries are created in metadata and tables are registered, folders have been created?
If this is the case, your users generally authenticate through the DefaultAuth, whether the authentication behind the scenes is AD or any other direct or indirect authentication.
The DefaultAuth defaults to the Metadata Server and the SAS servers it is using, such as Workspace Server.
If you have databases, such as Oracle, you can create additional Auth Domains in SASMC, such as OraAuth, using the DBMS userID and pwd for each DBMS connection.
Example: For each user ID, you'd either have to add an additional authentication domain, such as OraAuth, using their Oracle user ID.
This would authenticate each individual user. Whether they are prompted or not depends on whether passwords are stored in Metadata or not.
Alternatively, if you would not want to authenticate the users individually, you'd use the shared accounts you mentioned in your original post, and create a shared user in SASMC. This user would use the DBMS' user ID. The individual users would then have to be added to that shared user ID (as members). In this scenario, only the shared account would be authenticated, not the individual user.
If you create/work with metadata, as described above, you'd have more control over the "who, where and when". Auditing, logging would provide you with more details on what your users are doing.
"Directing"/setting up authentication might be easier as you'd have more control.
Examples for authentication mechanism
LDAP
Thanks
Anja
If your SAS servers run on Windows and you are using SAS/ACCESS to ODBC then its pretty simple to do Windows Authentication:
You can avoid the ODBC Administrator as well by specifying everything in a connection string like this:
http://support.sas.com/kb/52/777.html
If you are using Unix then the set up is harder as you need to customise an ODBC.INI file. Oracle set up is trickier too and depends if you are using SAS/ACCESS to ODBC or not.
It is also easy to set up ODBC connections in SMC by adding the connection strings to ODBC servers set up under the Server Manager. This is the best practice approach for SAS Server environments.
Thanks for your reply. we are right now running on unix (applications server) and the clients are running on windows. We have SAS/ACCESS to ODBC.
How are you authenticating to the Unix SAS App servers? Are you doing AD authentication there? I think you need LDAP configured for that but I'm not an expert in this area. If you've already got it going for SAS client connections then I suspect it will be a lot easier to delegate that to ODBC connections.
there is no ad users on unix. the ad user are translated to a shared user. security is however based on AD
I think manual login is the easiest solution as we use shared users (workspace context) for our users. Do you have abn example on how to set it up?
Hi,
One of the things you mentioned is
"the ad user are translated to a shared use", and "I prefer that the users sign manual up every time they use an authdomain", and "access to raw data".
First question:
How are your users currently reading these raw data into SAS/access the raw data?
Via BASE SAS, EGuide, DI?
One the raw data is imported and data sets are created, are the data sets stored in metadata libraries?
Since you mentioned SASMC, I assume that all your users are registered in Metadata, and that your libraries are created in metadata and tables are registered, folders have been created?
If this is the case, your users generally authenticate through the DefaultAuth, whether the authentication behind the scenes is AD or any other direct or indirect authentication.
The DefaultAuth defaults to the Metadata Server and the SAS servers it is using, such as Workspace Server.
If you have databases, such as Oracle, you can create additional Auth Domains in SASMC, such as OraAuth, using the DBMS userID and pwd for each DBMS connection.
Example: For each user ID, you'd either have to add an additional authentication domain, such as OraAuth, using their Oracle user ID.
This would authenticate each individual user. Whether they are prompted or not depends on whether passwords are stored in Metadata or not.
Alternatively, if you would not want to authenticate the users individually, you'd use the shared accounts you mentioned in your original post, and create a shared user in SASMC. This user would use the DBMS' user ID. The individual users would then have to be added to that shared user ID (as members). In this scenario, only the shared account would be authenticated, not the individual user.
If you create/work with metadata, as described above, you'd have more control over the "who, where and when". Auditing, logging would provide you with more details on what your users are doing.
"Directing"/setting up authentication might be easier as you'd have more control.
Examples for authentication mechanism
LDAP
Thanks
Anja
If you have the users defined in the Metadata against AUTHDOMAINS The users could manually update their passwords in the metadata with the SAS Personal Login Manager.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.