Enterprise Guide 4.2 and Office Addin 4.2 now have the ability to access OLAP cubes that are not registered in SAS Metadata.
Effectively this allows you to use the SAS tools to access non SAS cubes (assuming you have the OLEDB connector installed)
These are called Private OLAP Servers.
Following extract from 051-2009: What’s New in SAS® Add-In 4.2 for Microsoft Office explains it well.
PRIVATE OLAP SERVERS
Also new in 4.2 of the SAS add-in is the ability to define private OLAP servers. A private OLAP server is a direct connection to an OLAP server, rather than choosing one that is defined in metadata. The SAS Add-In for Microsoft Office now supports connecting to third-party OLAP providers, such as Microsoft Analysis Services or SAP BW, or any other vendor that defines an OLE DB compatible provider.
This is useful for users who have already invested in an OLE DB provider for OLAP. Now it is possible to use SAS to view and analyze that data. In SAS Add-In 2.1 for Microsoft Office, this was not allowed; the SAS add-in was able to connect to only a metadata-defined OLAP provider.
Once the user has opened the cube into the PivotTable, it works the same as any other PivotTable. The user has the full breadth of functionality available to them, such as drill-through, and adding calculated measures and members.
So looking for some help from the SAS community.
On a project we have focused on delivering content via Web Report Studio and Infomaps.
We now want to allow users to access the content via Office Addin and Enterprise Guide.
But (there is always a butt 
we only want users to access data via Information Map, we don’t want them to access the base libnames or tables.
Why you ask, because we have all the business rules embedded in the Information Maps so we don’t want users bypassing these and defining there own business rules on the base data.
Of course if we deny access to the libname then the Infomaps will fail. We can’t restrict access to all data types (i.e tables) in AMO or EG.
So any ideas out there?
Things we are going to try:
- Implement workspace server pooling (grant access to tables trusted user, but not actual use)
- Create a workspace server for WRS reports with full rights inherited and a workspace server for AMO/EG users with linbame rights restricted
But we are pretty sure that neither of these will work.
As the title says, Help!
I have talked to a number of customers that are having a problem with the SAS Addin for Microsoft Office (AMO) remembering a users password and then locking them out of their account.
When a user configures their connection to the SAS Server in AMO they can save their password, so they effectively gain a form of single sign on. (The password is stored as an encrypted text string in an XML file).
A number of customers I talked to also have some form of LDAP authentication setup (i.e. Active Directory), Unfortunately when a user changes their password on the LDAP server, AMO doesn’t know about it. It keeps trying to authenticate the user with their old password until the users account gets locked.
SAS Enterprise Guide also enables the user to store their connection credentials, but it seems to prompt the user to re-enter their credentials if the authentication with the server fails, therefore the users account doesn’t get locked.
We are working through some work arounds for this to see if we can fix the AMO issue, but has anybody else struck this?
Anybody else fixed it?