SAP Single Sign On Implementation Project

The end of the year, all slowly sum up.

For me, this year was remembered by the Single Sign On (SSO) implementation project between SAP and Windows. In this article I will talk about the experience of implementation and project management, pitfalls, findings and conclusions.

The company is a large transport company in Belgium, combining metro, tram and bus. There are more than 10 thousand employees, almost two thousand of them are backoffice, using many tools: corporate website, mail, application service, sharepoint, archivist and, of course, SAP.

SAP is everywhere: from accounting and HR to recording the movement of transport units, documentation of accidents, analytics, procurement, warehousing, etc.

Problem:

SAP for a PC user is a separate application that needs a password to access it.
First, the password must be requested, and then remember. Technical support forced to take calls to create and change passwords.
From the user's point of view, an extra password is unnecessary trouble. People store passwords on pieces of paper or make them too simple. Security screams gross violations.
The minimum password requirements for a PC do not match the password settings in SAP. If you bring them to a common denominator, it is better to immediately implement SSO.

Objective: to implement SSO between Windows and SAP, so that by logging into your PC account, the user can log in to SAP without entering a password.

If you do not deal with SAP you will be interested in this article from the point of view of project management, for the engineers of those details will be given (in brackets).

Under the cut:

Scope
1.1 Scope People
1.2 Scope System
Components
2.1 Changing System Settings
2.2 Windows Active Directory (AD)
2.3 SAP Secure Login Client (SLC)
2.4 Binding an SAP User to its AD
2.5 Modifying the SAP logon.ini file
Testing
SNC is a security hole
Teamwork
Information for business
Translation difficulties
Results and conclusions

Introduction

Looking ahead, if you are not eager to fill the standard bumps, here is a list of questions that you should clarify for yourself at the very beginning of the project:

Scope of the project (Systems, users - in what order we implement, where priority and what can be discarded if something goes wrong, which users should get access, etc.)
The main departments affected by the project (Even if the project is “tangential” for them, it is still important that everyone be aware of it beforehand)
Your credentials (There is not much you can take a run -.. In the European company everything is built on consensus and voluntary willingness to help if the department will say that they do not have the resources, the press and the "force" is almost impossible, but you can call a third-party consultant to assist, for example)
Deadlines (For the entire project as a whole and for specific parts)
Coordination procedures (Bureaucratic regulations - this is not the last question in a large company)
Possible difficulties (All. Possible. Difficulties.)

We have changed the composition of the project participants several times: at first it was only the SAP authorization department and the Administrators department (Basic Components). Then they were joined by the Windows authorization department (Active Directory, AD) and the update implementation department (Packaging), then the database department and the mobile applications department, etc.

For the technical side of the case, an external consultant was invited, and the Project Manager (PM) became me, as a person involved in authorization in SAP (therefore, the details on authorization in SAP in this article will be more than others).

An important clarification: all access that we give to SAP is customized. We do not use the standard roles offered by the system, but create new ones, under the department, under the position, under the functions. To date, we do not have synchronization between SAP users and Windows AD. For example, if your user has administrator rights in the local network, this does not mean that he is also an administrator in SAP.

1. Scope

1.1 Scope People

People in our company use SAP through the application on their personal computer (thin client - SAP Logon GUI), but not only. How to count users who fall under the distribution?

We took as a basis everyone who connects daily through the SAP Logon (SAP user type Dialogue) from laptops. In this category, the entire backoffice - employees of the administration, bukhi, ichary, developers, testers, logistics, etc.

Excluded:

those who have a desktop computer and not a laptop
8 thousand users who never open SAP logon, but use SAP through the website and applications (SAP user type Communication)
all external users (not employees, but must log in to the system via VPN)

1.2 Scope Systems

In our company, SAP uses six active landscapes ( ECC, BI, SRM, Netweaver, PI, Solution manager ), not counting sandboxes. Each of them has its DEV , ACC , PRD - i.e. in fact, it is 6 * 3 = 18 systems.

It was decided to take only the first four landscapes by public vote. PI and SM are used by a narrow circle of administrators and require upgrading the system itself (at least updating the SAP_BASIS component to version 740). Otherwise, the transaction sncwizard is not supported, but it is too troublesome for 10-20 people to do it manually.

2. Components

People interested in those details will find step-by-step instructions on the SAP website , as well as the various methods available (we chose SSO based on Kerberos , but this is not always the obvious option).

From a very simplified point of view (mine), SSO is an add-in to SAP that allows you to log in using your Windows account. You turn on the computer, enter the password, and in order to log into SAP you just need to double click.

For magic to work, you need 5 components:

2.1 Changing system parameters (instances of SAP)

In the SAP system ( ECC , BI , SRM , Netweaver ) you need to activate the snc / enable = 1 parameter . This is done through the sncwizard and includes preparation, system reboot and final activation steps.

We dealt with the parameters before and after with the help of those consultants, help from other departments and through trial and error. The hardest part was restarting the system.

It is always difficult to restart PRD in production, work goes on around the clock. And in a transport company, this is doubly difficult: transport moves from five in the morning until one in the morning, even on weekends. Any difficulties with PRD affect not only the company's employees, but the entire city and tens of thousands of people. In other words - you need to minimize the time when the system is unavailable and, if possible, to combine with other updates. At the same time, the bureaucracy should not be underestimated: the restart is the dates, time, duration (if the parameters are not saved from the first time) and the notification of the business agreed upon in advance.

We had four SAP PRD systems: ECC, Netweaver, SRM, BI - to reboot

ECC is the most important, all real-time data and the main transport are tied to it: buses, trams.

These Netweaver systems (crashes, mobile applications), as well as ECC systems, are used even at 3 am - if the trams do not run, then repair crews go.

The SRM system is mainly used for purchases and was available any day after 6:00 pm.

With BI, the difficulty is that on weekends, data flows from the ECC go to the system, and, moreover, sometimes reports from BI are used by top management outside working hours.

In total, it took 2 weeks to reset all PRDs.
PS Restart of each of the PRD systems was preceded by restarts of all DEV and ACC, which are easier to reconcile, but also require planning.

2.2 Windows Active Directory (AD)

In Active Directory, a special technical user (SAP Kerberos) is required. This user will contact Windows to get a copy of the input ticket for SAP. One such service user AD for all SAP systems suffices.

This part was entirely made by our external consultant and the Active Directory team, it included several iterations to refine the parameters and set up a special library, but for me to a greater extent it remained a “black box”.

This program itself does nothing. It is needed to store a ticket from AD, confirming your user when logging into a Windows session, and, if necessary, submit this ticket to SAP for authorization. SLC can be installed to all users at the beginning of the project at once - it will not work anyway without the rest of the SSO components.

2.4 Linking an SAP user to its AD user

As already mentioned, in our company there is no single user management, access in different systems receive from different teams. In this case, the user login in SAP is different from the username in Windows, for example, user # 45011 in AD is Ivan Ivanov or IVANOVI . It is this bundle that must be filled in the SNC (via transaction SU01, field SNC, p: CN = ADname @ domain).

There is no SAP Identity Management in our company. Therefore, it was necessary to solve two problems: the creation of new users and the updating of existing parameters.

Creating new users
In the main system (ECC), 4-6 new logins are created every working day, this is almost 1000 new users per year. The process is automated: when creating a user, the program fills its address, name, and basic settings. We decided that the program should also fill in the SNC field at the stage of creating a user, regardless of whether a person will need SSO in SAP afterwards or not.

The catch was that for each user, you need to fill in your own unique name in AD, i.e. this parameter is not the same for all - i.e. It is necessary that the program itself was looking for the user name in AD and filled it in SAP.

The developer quickly updated the program. The code and basic testing took 2 days, but the data for testing in ACC did not fit us (AD was not updated), so we immediately sent the changes to PRD. It turned out that everything is more complicated than we thought. In the course of the investigation, we came to this scheme:

First, users are created in the HR system (in SAP they can be seen in PA20 )
Then they are copied into the Z-table, along with the data about the department, position, position, is it a governing body, etc.
Then the data on users is sent to AD and here the system creates a user in Windows, and gives it a name in AD and mail
The PI flow in this scheme is just to understand that this is a third-party process of the third system.
The data is copied back to SAP (to the new Z-table), this time just the AD names and email addresses
At the last stage, the Z-program is started, which creates users in SAP ( SU01 ). Not all users who are created in the HR system will be created afterwards in SAP, there are quite a few who do not use SAP in any way.

It took almost two weeks to search, reconcile changes, agree on an update schedule and load and unload tables. It was a matter of synchronization - the user creation program (point 6) should be strictly started after all other programs have already been worked out and the data has been copied into the tables. As a result, we monitored for two weeks when which program was completed and at what time, and debugged the circuit.

When users are created with a filled SNC field, but without the necessary AD names, in SU01 you can see all users who are comrades in misfortune, tied to one non-existing AD user.

Updating the parameters of existing users
Precisely because our login SAP and Windows do not match, we could not use the standard solution from SAP to fill in the SNC field ( RSUSR300 via SNC1 program ).

As a result, I updated the data of 10 thousand existing users using a homemade script ( SAP eCATT ), uploading data to users manually and creating a variant. For success, we had to open up for change and eCATT systems in PRD and ACC and promise developers millions of cookies.

2.5 Modifying the SAP logon.ini file

Technically, this is a 1 minute deal. It is only necessary to note in the file properties that the connection is available via SNC .

The difficulty is that this file is locally on the user's PC and it is necessary to change it from two thousand users.

In fact, for us, the final implementation was the moment of distribution of the new sap.logon.ini file among users, and not a change in the PRD parameters. Because even if the first four components have already been made, and the last fifth is not, then magic will not happen.

With the last item came a small incident. I reported to the management that we have 2000 users, who will have the update installed, and when it was time to implement, they sent me the status, where there were 3,500. It was not easy. This is because, for my part, I saw only active SAP users, and in fact the update was sent to all personal laptops, of which there are much more in the company. Thank God there were no bugs from the technical side.

3. Testing

How to test SSO? Either it works, or not. Our developer snorted and said that testing is not necessary, and as soon as everything works in the sandbox, you need to send it to production. Of course. Nobody will say he writes code with bugs.

It is necessary to check:

Does logging into SAP work with SSO immediately after a reboot
can users use SSO when connected with VPN
Difficulties for developers for other systems, for modifying SAP logon

SSO is not a program, it is difficult to implement it consistently DEV - ACC - PRD. Nevertheless, primary testing is necessary to catch everything that could potentially go wrong. Testing in this case is the distribution of the new SAP logon.ini, when all components are already running. We tested DEV and ACC with developers and a new SAP logon.ini with PRD with a sample of business users.

What you found:

sometimes (1 case for 500) it is necessary to completely reinstall the SAP logon or SLC
key users who have rights to change other users (about this in the next paragraph)

4. SNC is a security hole.

What about modifying the SNC field?
The fact is that by changing the SNC field of another user (in SU01) to your own, you can connect under someone else’s account, even without changing the password. The system will simply ask you which user to choose, yours or someone else's. At the same time, if you do this, tomorrow nobody will notice anything, because the password has remained unchanged.

In any company there are people who are involved in user management . Typically, these people monitor the creation of users ( SU01 ) and access for them ( PFCG ), as well as updating passwords. It is perfectly logical that they can also fill in the SNC field .

The problem arises when the company needs to separate user management and just key users. Administrators create users, and key users change their data if necessary: the user's settings, his language, his location, etc.

In SAP, there is no separate monitoring step for changing the SNC field. All who have rights to change the user (object S_USER_GRP, ACTVT 02 ) can also change the SNC field (whereas the same object is required to change the password, but with ACTVT 05 ).

There may be several solutions:

take access rights to SU01 from key users, and in return give everyone SU2 and SU3, where the user can change his own parameters
take access rights to SU01, and in exchange give a z-transaction where the SNC tab will not be shown
leave SU01 but protect the SNC field with special control

We finally chose the last option, making custom authorization object and tying the program SU01 on it. However, as it turned out later, SAP has a similar solution - you can activate extended maintenance ( note 1882254 ) for individual fields SU01.

5. Teamwork

During the project, I faced all the difficulties of teamwork and discovered many basic truths for myself:

Time does not happen much . Time is the best that PM can foresee.
There should be a basic project plan , but it should be reviewed every week, leaving a large margin for flexibility. Somewhere we moved faster, somewhere trampled on the spot.
Adult uncles in the IT department sometimes do not differ in behavior from girls in accounting : they refuse to work with each other, simply because they don’t like the person. And it is required to once again settle the issues of subordination.
Often, the departments slow down the coordination of the project , because it is not clear on whose responsibility the implementation lies and on whose budget additional hours of work fall. It is important to give managers everything to discuss directly.
Every now and then there are unforeseen situations . The best that can be, is timely communication, letter, call, SMS to all involved people.
There is nothing better than a personal meeting . Questions are solved many times faster than during the discussion by mail. On the other hand, all personal arrangements must be immediately followed by a subsequent letter (to consolidate and not forget)
PM in an IT project can only trust people . In fact, you have no idea how much time it will take to take one or another action: for example, creating a user in AD for Kerberos, 10 minutes or three days? And there is no way to check whether testing was really stopping or someone was fooling around. It remains only to trust.

In addition, a lot depends on the consultant’s perseverance. Someone one, or a consultant-developer or PM should be like a bullet, impudent and pierce the walls of the bureaucracy. In this case, I was partly lucky, our invited consultant was annoying and sometimes unbearable (it was difficult to get him to hear something), but he knew his business: he reported any problems and stops immediately and did not calm down until the problem was resolved.

6. Information for business

In a large company, changes affecting end-users should be timely, or better announced in advance.

In our case, it was necessary to inform all users that they no longer need a password to log in to SAP. Also, it was necessary to provide technical documentation for the 1st support line with all possible errors that may arise after implementation.

I must admit that with communication everything that could have gone wrong.

First , we announced the users about SSO on the corporate site, not a letter. How often do you read the corporate website? Many simply did not notice anything until their SAP suddenly stopped requesting a password.

Secondly , the girl responsible for posting information got sick, relegated, did not check, I was told to wait a week, I refused (in the end, due to an alert, to delay the project?) And my text was on the site without reading, with a bunch of signs.

Thirdly , tech support wrote to me on the day of Go Live that they do not support changes, if the documentation came to them in less than a week (I sent the documentation in 2 days), and that in the case of calls we will get out for ourselves. It is good that there were no technical errors.

7. Difficult to translate or last fuck-up

The project started and was already in full swing on the 5th day of the SSO era in our SAP, when we found an elephant that no one noticed.

The company has two languages: Dutch and French. A priori, since the company is located in Brussels, everyone has French. Nevertheless, many employees connect through Dutch or English. A total of 2,000 active users, almost 500 people are Dutch-speaking. Previously, they themselves each time changed the language in the connection window.

Now everyone is defaulted to French. And if we left the tick “use a default language SAP logon” empty - there would be no questions, everyone would connect with the language marked in the parameters ( SU01 , Defaults tab ). After the introduction of calls fell down with a request to "change the SAP user . "

At the testing stage, the problem was not noticed, because almost all testers were French-speaking, or were connected in French in their daily work.

Solved the problem by sending instructions on changing the language to all Dutch-speaking users in order to prevent their new calls in technical support.

8. Results and conclusions

In general, implementing SSO is easy when you have already done it at least once in your life. They say that this is a question of 1-2 weeks of work, but not 3 months.

In fact, it all depends on the size of the company. Each company has its own characteristics and a lot of energy and resources is spent on understanding these nuances. In our case, three months were exactly as long as necessary for all meetings, approvals, changes.

Many things about SSO were probably already known for a long time, at least by Google. For example, about the server request to AD, or the SNC field. But there is such a thing as the eternal lack of time. As a specialist, you are obliged to google, and as a project manager (especially if you cannot figure out the first half hour, and you do not have a specialized education) - you must find the shortest way to the solution.

Как правило, самым коротким путём оказывается спросить, причём спросить устно.

Dry residue:

The main time in 3 months was spent on coordination and coordination of actions.
The departments involved in this project have begun to better understand each other’s work.
During testing, you need to represent yourself in the place of the end user - what would you like to see in the information message, and in the basic settings.
SSO for SAP is implemented. Users are happy and have already forgotten about the times when they had to remember the password from SAP. In technical support call less often, hurray.

Tags: