Is EG able to connect to a Unix SAS server using AD?

[deleted_user]

I was reading http://support.sas.com/rnd/itech/doc9/admin_oma/security/auth/security_imptrust.html and I wonder if EG is able to connect to a unix SAS server (running SAS IT) using credentials provided by AD (without the use of an LDAP server in the picture). This is the one-liner that I base my concerns on
"User IDs that are used to connect to servers via the trusted user or trusted peer session mechanisms do not need to have an account on the authentication provider for the SAS Metadata Server's machine". Does that imply that all we need to do is to configure the user credentials under SAS management console, and the user session will be able to login using his Active Directory provided username and password?

Thanks for your advice in advance, Josh

[deleted_user]

No.

There are two logins involved:

1) Connecting to either the metadata server or the metadata repository, which requires the AD login authentication of the EG user. I may not be stating this precisely correctly, but the point is, if the user isn't in the MetaData repository, he/she can't use any remote EG resources.

2) Connecting to the remote server.

There are a number of ways for EG to connect and authenticate to a remote server. At the very least, there is a single Unix account -- let's call it SAS_EG -- that is used by EG to connect to the remote server. At the very most, there is an LDAP product that allows EG to use the user's ID to connect to the remote server.

As examples:

At my previous place, we had a logical server for each group that used SAS. For each of these groups, there was a respective Unix account, which provided a common repository for that groups stuff. It allowed/provided for isolation of the groups from each other for processing efficiency, storage separation, and a certain measure of security. Each user had to be listed in the list of users in the EG metadata repository, and each user was then assigned to a group. Each logical server had access limited to a particular group, and used the group's Unix login ID to connect/login to the Unix box.

At my current place, we have a SAS MetaData Server. A script clears its set of users and repopulates it from AD every night. Through AD each user can access a remote logical server through their individual login id. The remote logical server runs on a Windows server, here. Because of this established mechanism, and a current lack of LDAP for our Unix servers, we are not able to make use of a Unix server for a SAS server (which is a bummer, since we would greatly benefit from the 64-bit processing and faster more efficient IO).

[deleted_user]

I was certain of a). The part on b) isnt very clear on the documentation. But as long as there is one local unix account, shouldnt a) take precedence over b), meaning that you can have 10 users connect to 10 logins on a), but all ten logins ride on the same one unix account for b).

I would think that once you create a user under SAS management console, and define the user logins under that account, you'd be able to cater for both a) and b)

[deleted_user]

I'm not understanding what you are meaning by "a)" and "b)".

I believe from previous "conversations" you have a common Unix SAS server.
So, minimally, create a Unix account -- let's call it SAS_EG -- with some password.

When you create the logical server to connect to the Unix box, for authentication, explicitly provide the userid ("SAS_EG" + the password for "SAS_EG"). In this way the users of the server don't need to know either. Then, create a group, and then limit access to the logical server to that group. Finally assign the SAS users to that group, explicitly.

Whenever there is a new user, they must be entered into the metadata repository and then added to the group.

Why the double work, why not simply control access by explicit user instead of a group. Because, if I remember correctly, when you create the user, you can assign them to one or more groups at that time, single maintenance effort. If you did not use group control for access, then, after adding the user, you would have to open the properties for the server and add the user to that server.

A logical server is either available to everyone, or has limited access, controlled by users and groups. I think it is better to simply use group limits as a good practice/discipline to better control security.

[deleted_user]

Sorry about that. I was thinking of 1) and 2) but put them up as a) and b) instead. I am still tinkering with SMC, but my worry is that by centralising all 10 users to one single unix account (for the login spawned by SAS IT), will there be a conflict of how each user's workspace is defined, because we'd want 10 independent home directories for each of 10 users.