BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
ANLYNG
Pyrite | Level 9

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.

1 ACCEPTED SOLUTION

Accepted Solutions
anja
SAS Employee

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

 

PAM
http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#n0bggv0uyqm3m0n1ng...

 

LDAP

http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p1k1qcvnbfsy0en1lz...

 

http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p0fpi70ptqcdldn1so...

 

 

Thanks

Anja

View solution in original post

9 REPLIES 9
SASKiwi
PROC Star

If your SAS servers run on Windows and you are using SAS/ACCESS to ODBC then its pretty simple to do Windows Authentication:

 

http://support.sas.com/documentation/cdl/en/bidsag/68193/HTML/default/viewer.htm#p1t9q2knb9tq5ln101d...

 

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.

ANLYNG
Pyrite | Level 9

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.

SASKiwi
PROC Star

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. 

ANLYNG
Pyrite | Level 9

there is no ad users on unix. the ad user are translated to a shared user. security is however based on AD

LinusH
Tourmaline | Level 20
Manual login is the easiest, requires no (almost) maintenence. If the users should supply their useris/pw each time you don't havery to register anything in Metadata.
But why are you in favour for manual login? I would classify it as less secure than automatic.
Data never sleeps
ANLYNG
Pyrite | Level 9

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?

LinusH
Tourmaline | Level 20
The point is that you really don't set it up.
Just register your ODBC libraries in a separate authdomain. Users without an account in this domain need to supply a login with their connection. Bare on mind you can't have those libraries as pre assigned.
Data never sleeps
anja
SAS Employee

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

 

PAM
http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#n0bggv0uyqm3m0n1ng...

 

LDAP

http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p1k1qcvnbfsy0en1lz...

 

http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p0fpi70ptqcdldn1so...

 

 

Thanks

Anja

twocanbazza
Quartz | Level 8

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.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 9 replies
  • 6976 views
  • 1 like
  • 5 in conversation