I work in a large company, and I'm interested in best practices for internal security standards. We have a large ($500 million +) investment in SAP, and we also have .Net and a bit of Java EE in our internal environment.
I've found some documentation from MS and SAP, but it's outdated and not very specific.
So far, it looks like we could end up using Active Directory as the standard user store for all non-SAP applications, and SAP CUA / Portal for SAP applications.
Some concerns I have about AD are:
Being able to aggressively time-out for applications on shared computers (A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine immediately after)
Being able to force the user to enter a username and password instead of just having the credentials read from the user's workstation - Because it's pulling the same credentials for the desktop and email, it won't currently ask users to log in. This is a concern for applications on shared computers as well. (See the explanation in the previous bullet)
As far as synchronization between AD and CUA is concerned, I want to approach this very carefully. We have a limited budget, and I want to make sure that if we end up putting something in place to synchronize the stores, that it's rock sold and provides excellent value. If we can't find something like this, I'd be comfortable coming back with a recommendation that the stores remain independent. SSO would be ideal, but I've worked with trying to get an SSO application up before SAML, and it wasn't pretty.
Acronyms:
SSO: Single Sign-On SAML: Security
Assertion Markup Language
CUA: Central User Administration (For SAP)
There is a lot of possibilities on this subject.
We had a customer that updated both their AD and their SAP user list from SAP HR. The idea was that the OM module contained all employees. You could export daily a list of all active employees to the LDAP, with basic informations (firstname, lastname, employeeId, login...). For the SAP system, unit/function/job needing a sap access where tagged and user where created/removed daily.
In fact, all employees had a SAP account, but only those tagged had a "dialog" one. Those account are allowed to connect via SAPGUI, others had to use the portal, which is a less costly licence. A set of rules allowed to set the roles for the managed users. The goal was to minimize user management and limit the inexorable grows of autorisation that comme from moving from job to job an organisation. (this was for 105000 employe, with a lot of personnel movement).
Thus SAP was not directly linked to the AD, but they where synchronised. Depending on the system (Development, qulity, integration, production), SAP was configured with time-out. You could also have différent password for separate systems.
Of course the reverse is also possible : interrogate a LDAP from SAP to manage SAP's accounts, without beeing directly linked to the LDAP. transaction LDAP can problably give you some informations.
hope this helps
Edit : the synchronisation was done by an ABAP program. that program was run every day at four, and created/deleted/modifed some accounts in the LDAP. After that, another program added some technical informations to the LDAP entries, informations that where not available to the SAP RH system (such as the mail server to use for a given employee, depending on its location around the world). The entries where then checked for consistency, and send to the master LDAP.
This program only managed personnel and units. Groups (authorization for others application) where managed either manually, or by others programs. Thus non SAP data were also stored in the LDAP.
Regards