Whilst it is possible to configure the SAS Metadata Server to authenticate users directly against AD/LDAP, it is not the most common approach. Normally the metadata server is left in its default configuration which passes authentication requests to the host operating system which then authenticates them against its own authentication provider (often AD, so that the metadata server is indirectly authenticating against AD). The approach you have taken, in configuring for direct AD/LDAP authentication, is normally only done when the metadata server needs to authenticate against a different server than the host operating system (e.g. a dedicated LDAP instance of external users where AD might be for internal users).   For the SASApp server, and the encompassed workspace server, it is the SAS Object Spawner that handles authentication to start a workspace server for the users on request (most commonly). The object spawner does host authentication and cannot be configured for direct AD/LDAP like the SAS metadata server can (because it may have to launch processes on the server as the requesting user). This is probably why you are seeing those prompts. In the most common scenarios, where both the SAS Metadata Server and Object Spawner are both doing host authentication (usually back by the same AD environment), the credentials used to authenticate to the metadata server are cached by the client and offered to the object spawner and, assuming no mis-configuration, the user gains access to a workspace server without being prompted for additional credentials.   If the direct AD/LDAP configuration for the metadata server is deliberate and correct, then you have the option of re-configuring the workspace server to support SAS Token Authentication. With token authentication the metadata server is used as a trusted authority and a service account is used to launch workspace server instances (given the user either has no account of their own on the workspace server machine, or no credentials are available for host authentication). Be aware there are some potential downsides to SAS Token Authentication (which are covered in the docs).   All of this is covered in the SAS documentation, but as a large flexible enterprise platform there is a lot of it, and it can take a while to read it all or find the bits you need. As a new SAS Administrator, I would thoroughly recommend you take the SAS Platform Administration Fast Track course, as it teaches these concepts. I would also recommend reading through the SAS Administration documentation. ... View more

As others have already suggested, obviously you should only go to the effort to creating and maintaining additional protections that are proportionate to the sensitivity of the data and the risk of inappropriate access. If your content is already adequately protected, according to organisational requirements, then why add the complexity of SAS Metadata-Bound Libraries (MBLs)?   You may have already seen them but just in case, and for the benefit of others who may be following this thread, some good documentation references that discuss the appropriateness and benefits of MBLs include the following:   SAS 9.4 Guide to Metadata-Bound Libraries Who Should Use Metadata-Bound Libraries? Permissions for Metadata-Bound Data Providing Fine-Grained Access Using Condition Permissions Providing Fine-Grained Access Using Views To try to provide another perspective I will pose some questions/scenarios where MBLs can provide benefits. These may not apply to your situation but may help show some situations where MBLs can help. If these examples don't help directly then perhaps they might still explain why it can sometimes be useful to have the additional flexibility they can provide.   Securing content through multiple authorisation layers (that have both common and unique features) can be done for several reasons e.g. defence-in-depth - redundant layers may provide protections when other layers fail due to accidental or deliberate changes completeness/flexibility - taking advantage of features not available in preceding layers e.g. row/column level permissions user experience consistency e.g. don't show users content they wouldn't have access to in preceding layers   A question I often see is why use metadata permissions (and perhaps MBLs) when operating system permissions can be used?   Leaving aside the defence-in-depth argument, sometimes it is not possible to rely purely on file system permissions. Consider SAS tables being accessed within the context of a SAS Stored Process Server, SAS Pooled Workspace Server, or SAS Workspace Server configured for SAS Token Authentication. The operating system identity is the same for all users - a service identity. In this case SAS metadata authorisation allows for finer level access controls than is possible with file system access controls. In this situation SAS metadata access controls allow you to control access for the requesting SAS identity (preferably through SAS metadata groups) where file system access controls cannot.   Why use metadata permissions when people can just use the libname-loophole (as it is often called)?   If you have configured SAS metadata access controls for SAS tables then there is the potential for SAS coders to bypass the metadata permissions by coding a base engine libname statement to get direct access to the data. If your file system access controls mirror your SAS metadata access controls then this may not be a concern, but if they need to be different, perhaps due to service identity use or row level permissions, then MBLs allow you to prevent this bypassed-access and enforce the additional use of the metadata authorisation layer.   How do I ensure row/column level permissions are enforced?   Some organisations have requirements to limit access to subsets of data based on filter conditions based on the requesting identity. In the past this has been done with SAS information maps over the tops of SAS tables but then you had to consider 1) people bypassing the information maps and going directly to the tables and 2) information maps were not as widely accessible as SAS tables. MBLs allow permission conditions to be applied at the SAS table level. This is as low as you can go since these types of access controls cannot be done at the file system level.   SAS tables in MBLs also have a wider range of metadata permission support than SAS tables in traditional libraries. Imagine you have a custom application requirement where users can add new data to a table but not modify or delete that data once added. By using a MBL and ensuring their effective permissions are +S, +I, -D, -U then you constrain them to view and add data but not delete or update it. If that person could gain file system access to the underlying table then adding encryption prevents them from copying the table to another location, modifying the data outside of the MBL and moving it back again.   Whilst I think that the responses so far have probably already answered the questions for your scenario, I hope this has helped add some general insight on where MBLs can be useful or even required.   ... View more

Using the Metacoda Identity Sync plug-in you would just configure it to target the SAS_Users AD group and then it would follow the members of that group, both users and and further nested groups and their members.   To do this with the importad.sas code you would need to customize it so that, instead of getting all users and groups under the specified OUs, you query the single SAS_Users AD group to find its members (as a lookup table) and then fetch the details for just those member users (and possibly member groups if you need nested groups too).  ... View more