SAP in its own Extra Active Directory Domain

[Former Member]

Our SAP system was installed on Windows in a separate, dedicated AD domain.

The SAP installation manual states:

"In Windows, the SAP domain and user domain must be incorporated in a domain tree. In this tree, the user accounts must form the root domain and the SAP domain must be a child domain of this."

I recently discovered that this was never done. The SAP domain and the user domain are completely separate. Further, there are no trust relationships between the two domains at all.

The network administrator is now concerned about how to implement this after the fact.

Can anyone provide information as to the steps required to accomplish what the installation manual states and how the domain structure needs to look?

Thanks and kind regards,

Rex L. Farris

[markus_doehr2]

You need that kind of setup if you plan to use some kind of Single Sign On or if you want to e. g. incorporate your print servers.

The SAP system itself will work without AD integration.

--

Markus

[Former Member]

Markus,

Thanks for your feedback. You're right - we're running into problems with cross-domain resource sharing (i.e. print servers, file shares). I was wondering if anything could be done from a domain structure perspective to solve these problems.

Rex

[markus_doehr2]

This is not changeable, at least not by default. An experience AD administrator will maybe able to put the system into a different AD tree but many things would need to be done if you do that manually (permissions on files, registry keys, services etc.)

The best approach would be (in my opinion) to get a spare box, install it as member server of the other domain and do a homogeneous system copy for your SAP system to copy everything over. Depending on the size of your system and your availability requirements this may be feasible on late evening/night or on a weekend. I personally would not start to fiddle manually or do a domain switch, all kinds of issue may arise...

--

Markus

[Former Member]

I've switched SAP systems between domains before now without problems.

You need to make sure that your SAP user/groups are in the new domain.

When you add the server to the new domain that will change your hardware key so you'll need to apply for a new license.

The new domain users will need to be assigned the relevant user rights on the SAP servers and set up the environment variables. The installation guides will tell you how to set up the users manually without the install doing it.

The Windows services will need to have the new users assigned as the start credentials.

On the local server, put the new SAP domain users into the local SAP group for access to the /usr directories, sapmnt shares etc.

Doing it that way, you've not got to bother with changing hostnames, IP addresses.

I'm not sure that I read what version or components that you've got installed but if you were to change hostnames for the new server then various parameters in the JavaAS would need changing.

I'd switch domain rather than system copy as I believe that it is less work and hassle.

[markus_doehr2]

It MAY work but from a security point of view, it can be critical since you need to change

- the permissions/ACLs on the registry keys (they don´t get changed automatically)

- the permissions/ACLs on the filesystem

Of course, you can give "all rights" to the users or even assign the administrator group to the new adm, this may open security holes you´re not yet aware of. Technically it will work, no doubt.

A system copy is pretty fast and straightforward doing backup/restore and will make sure, your company security policies as still intact.

--

Markus

[Former Member]

But for the security, the rights are normally given to the group SAP_Localadmin so if you ensure that membership is right, the security should be fine.

There are pros and cons for the different approaches and really depends how comfortable the basis team are with SAP. The system copy is documented and if I were to follow that route, then I would probably rename the source system and change the IP address - then the target system could use the original hostname and IP address which saves having to adapt RFC destinations and users/systems should be able to access the server without making changes elsewhere.

One thing that I missed off the post was to ask what the DB is. For the domain switch there are different actions needed for MSSQL and Oracle.

For Oracle you've got the OPS$Domain\SAPServiceSID user (and associated SIDadm user) that you'd need to create, assign roles, synonyms for SAPUser table etc. Couple of scripts available from SAP that sort that out fairy easily but nonetheless one of the things that I missed.

MSSQL will need to have accounts for the new domain users also and set their default database etc.

Whilst I didn't use AD for my printers, I did use SSO from users in one domain to logon to SAP in another domain and they were both top level AD domains - I just put a trust in. Perhaps implementing a trust would just save a lot of hassle?

[Former Member]

Thanks for the responses. My mistake for not specifying that this is a SQL Server 2005 database in a Windows 2003 Enterprise Edition environment. Anything tidbits that need to be done to accommodate SQL would be helpful.

Rex