04-29-2014 11:47 AM
I would like to know about LDAP authentication and AD usage. I am currently on Windows and use the network credentials for authentication.
Please let me know if any one of you have implemented LDAP/AD group on windows.
04-29-2014 02:21 PM
akshatadeshpande, AD is some kind of LDAP. ou dn cn approaches are commonly shared (ldif)
As you are running Windows you are part of an AD domain. Autorization by groups is quite common with AD/Windows
Would you run Unix than the administrator can setup an LDAP domain to behave in the same way as Windows, however that is not a default approach as with Windows. That is one difference another is:
The users and groups with Windows (AD) are being identified by long Uri-strings at Unix those are just integer numbers (id/gid). These number can have low or high limits dependent on the OS type/version. By that you cannot integrate Unix/Windows that easy.
When you run SAS with at least a good host security model and when possible using host-authentication you will get the best and easy way for high demanding analysts.
04-29-2014 04:40 PM
Thanks for your reply. Yes we have an AD group for SAS that has been set up and the new users are added to this AD group.
Once they are added, i build them using the SAS management console and assign appropriate roles and groups.
In our company, we have different groups for sas users like banking,agents,clerks etc.Can different AD group be created for each of these SAS groups and when the request for the new user comes up, the user can be added to the approriate AD group so that it is not required to create that user in SMC?
Can this be done? Please let me know your views on this.
04-30-2014 03:16 AM
akshatadeshpande, You did not mention your SAS server environment as it can be Windows using AD or Unix (Linux) possible with LDAP.
At the high level organizations are doing RBAC (Role Based Access Control). There are just 4 object-collections types involved:
2/ Groups (they way to authorize)
3/ Business data/software (can be just storage location or complete processes)
The hardware and OS are not visible for the business at this level. There can be many cross relation ships that are part of the installation/configuration of the middleware (SAS), the definition of an SAS business application (regular) and the SAS business environment (adhoc).
The goal should be maintaining the operational security is adding/changing/removing:
a/ users/accopunts as indentities to the mentioned systems.
Ssytems can be the involved OS(*), RDBMS(*), SAS-metadata.
b/ Connecting users/accopunts to groups at the mentioned systems.
Bypassing this identity within SAS-metadata is not possible to bypass as you cannot bypass that with a RDBMS (eg Oracle).
Running with shared accounts and ignoring security requirements is often done but for log run not advisable. Your question is indicating you are in the financial area and your company will have to deal with regulations like SOX-404 ISO27k Cobit ITSM etc. That all comes down that actions/information must be traceable and auditable to accountable human beings.
As SAS metadata with their folder approach is evolving to a complete storage approach like Windows folders you could set up the SAS metadata in a similar security model (users/groups) as Windows (Unix).
Than you can define a synchronization approach as described in SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (Overview of User Bulk Load and Synchronization). The sample code is available at your installation.
This will be a trade off in building/maintaining this process by doing it by hand. With 400+ users looks to me the effort will pay back, with 10 users not.
04-30-2014 04:27 PM
Jaap, i am currently on SAS 9.3 which is installed on Windows 2008 R2. We have an AD group created on Windows and the new SAS user will be added to that group.
05-01-2014 01:54 AM
If you have the sas-metadata group named similar like your AD group.
What is your issue propagating the request to AD to the SAS metadata, by hand or by code?
As explained a vanished registration some magical event is not to be expected.