09-25-2013 05:51 PM
I`d like to know if it is possible that the task of registering /user/groups/roles may be made by different server context administrators.
e.g. : Mr. A registers users in SasAPP-A
Mr. B registers users in SASAPP-B
this is because SAS is active in different remote areas and we don`t want to have an only administrator for all.
thanks in Advance!
09-25-2013 08:35 PM
It's hard to answer your question without asking many more questions about your environment and your requirements. I'm assuming that the different regions have a single shared metadata environment (and not isolated/independent metadata environments).
Without knowing more, as an example, let's assume that the ultimate goal is for a SASAppA-Admins group to be able to self-manage who has access to the resources of the SASAppA application server and that this will be handled via membership of a SASAppA-Users group. Let's also assume that the members of SASAppA-Admins are not administrators themselves and cannot register users (and that it is done via AD sync). All they should be able to do is add and remove existing users from the SASAppA-Users group (this is one of the simpler configs to manage). To mirror this there will be a SASAppB-Admins group self-managing membership of a SASAppB-Users group that has access to the SASAppB server. The users of SASAppA-Users cannot see the SASAppB server, the SASAppB-Users cannot see the SASAppA server, the SASAppA-Admins cannot manage the membership of any group other than SASAppA-Users and likewise the SASAppB-Admins cannot manage the membership of any group other than SASAppB-Users. Given these sample requirements, the following access controls could be used:
+SAS Administrator Settings ACT
Of course there are other things to consider too, such as the current configuration the Management Console and Metadata Server roles, but I hope this gives you food for thought.
If the "admins" for the SASAppA and SASAppB servers also need to be able to manually create users (i.e. it is not being done automatically via enterprise directory synchronization), then they will need to be members of the Metadata Server: User Administration role and things become trickier. Membership of that role gives them automatic access to manage almost all groups/roles and so you have to consider taking away that access and explicitly controlling who can manage which groups/roles. This type of configuration is likely to be fragile and difficult to maintain so I would consider other alternatives first.
If security is critical for your environment and it is not an area you are comfortable with yourself, I would definitely recommend getting SAS professional services or a local SAS partner in your region to help you with this.
09-26-2013 08:05 AM
You´re right I omitted those details.Excuse me. In our environment we share the metadata server, SASApp-A users only see SASApp-A Sas objects. But a question: can you give me more data about :
SASAppA-Admins are not administrators themselves and cannot register users (and that it is done via AD sync). How do you implement this AD sYNC.
thanks a lot for your answer!!!
09-26-2013 04:45 PM
Yes Silvia Appendix A, the "user import macros" (sample)
The idea can be having same like groups in the metadata as in AD and with using ACT-s granting the needed assets in metadata.
As long you are running SAS servers in the Windows environment you are pretty save and sure to set-up the host-controls.
That is securing all the OS(Windows) assets (directories/files) you have and can secure using groups in AD.
If you have Unix servers it get more complicated on that part.
09-26-2013 07:06 PM
Oh Jaap, I really appreciate your answer!!. I have downloaded the document and I am reading it. Our environment is in UNIX but we'll try to do our best.
Thanks a lot!
09-27-2013 12:59 AM
As Jaap mentioned that is definitely the right document to be reading. Being on UNIX it would be a good idea to talk to your sys admins to see how your users are being managed. Some UNIX installations use Microsoft Active Directory as a directory and authentication provider and so you may be able to source your user information from there for automated user synchronization (see the sample importad.sas code mentioned in the documentation). Alternatively they may be using another vendors LDAP server - which could also be used as a user/group information source (the same SAS ldap functions are used to query the directory but the code will need to be modified - I have heard that you can contact technical support for similar importldap.sas sample code but I have not seen it myself). If the user accounts are local (unlikely unless there are a small amount of them) then there is also importpw.sas sample code that can use an /etc/passwd file as the information source. Essentially, if you can get the data about users, groups and memberships from somewhere (LDAP, CSV, XML etc) and can load it into the canonical tables you can use that as an identity source for identity synchronization.
09-27-2013 01:06 AM
I started a poll as being curious how other people are handling this chgallenge. Linkedin "SAS Professionial Forum".
Would like to see more voters.
Interesting on this point is of your architecture is like "on demand" "SAAS" whatever you call it dealing with Multi-tenancy. You described this as being your requirements. http://support.sas.com/resources/papers/proceedings13/494-2013.pdf . See the note about sassrv usage.
As long as the SAS admin person won't be member of one the business Application-environments you can set-up procedures for auditing/security-monitoring and more. By that you are able to fullfil some of the more very strict requirement/policies on that part. Be aware that the weak part of SAS metadatasecurity is that is open by nature. I am aiming at the requirement that the SASusers group must have RM rights in the default ACT.
One good source on some advanced topics on this is Paul Homes blog.
09-28-2013 06:27 PM
Jaap - thanks for mentioning my blog. That's a good SASGF13 paper too.
Silvia - another possibility, depending on your requirements, might be to provide mediated/controlled admin features. Custom stored processes (for which you can control access) could potentially be used to perform specific admin requirements without needing to provide broader SAS Management Console access. As an example, Steve Overton wrote a SASGF13 paper where he showed the use of stored processes to provide a user interface to controlled Active Directory identity synchronization: Automagically Herding 101 SAS Users from Microsoft Active Directory to SAS Metadata. Whilst his paper is about AD the concept can also be extended to other directories. I can also imagine a similar use for specific group-admins controlling the membership of their groups. Of course, you need to weigh up the benefits of such an approach with the ongoing skills and maintenance requirements to keep it working over the years and SAS versions.