Geekly Articles each Day
📜 ⬆️ ⬇️

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 everywhere: from accounting and HR to recording movement of transport units, documentation of accidents, analytics, procurement, warehousing, etc.


Problem:



Objective: to implement SSO between Windows and SAP, so that by logging in to 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:


  1. Scope
    1.1 Scope People
    1.2 Scope Systems
  2. Components
    2.1 Changing system parameters
    2.2 Windows Active Directory (AD)
    2.3 SAP Secure Login Client (SLC)
    2.4 Linking SAP user to his AD
    2.5 Modifying the SAP logon.ini file
  3. Testing
  4. SNC is a security hole
  5. Teamwork
  6. Information for business
  7. Translation difficulties
  8. Results and conclusions

Introduction


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



We have changed the list of 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 I became the Project Manager (PM) 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 is the administration staff, bukhi, ichary, developers, testers, logistics, etc.


Excluded:



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 by a public vote to take only the first four landscapes. 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, and 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 (of 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.


To make magic 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 preserved the first time) and the notification of the business agreed upon according to the rules.


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 teams 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, besides, 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 large extent, it remained a “black box”.


2.3 Installing the SAP Secure Login Client (SLC) software on the user's computer



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 right away — it will not work anyway without the other 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.


Create new users
In the main system (ECC), 4-6 new logins are created every working day, this is almost 1000 new users in a 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 a unique, own 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 at 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. During the investigation, we came to this scheme:



  1. First, users are created in the HR system (in SAP they can be seen in PA20 )
  2. Then they are copied into the Z-table, together with the data about the department, position, position, is it a governing body, etc.
  3. Then 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
  4. The PI flow in this scheme is just to understand that this is a third-party process of the third system.
  5. The data is copied back to SAP (to the new Z-table), this time just the AD names and email addresses
  6. At the last stage, the Z-program is launched, which creates users in SAP ( SU01 ). Not all users who are created in the HR system will be created later 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 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 existing user settings
Precisely because our SAP and Windows login do not match, we could not use the standard solution from SAP to fill out the SNC field ( RSUSR300 via SNC1 program ).


As a result, I updated the data of 10 thousand existing users using an improvised 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 are already 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 2,000 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 felt uneasy. 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:



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:



4. SNC is a security hole.


What about the modification of 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, if necessary, change their data: 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:



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:



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 kind of 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 occur 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 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 are connected via Dutch or English. A total of 2 thousand 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 problems were not noticed, because almost all testers were French-speaking, or were connected in French in their daily work.



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


8. Results and conclusions


In general, implementing SSO is easy when you have already done this 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:



')

Source: https://habr.com/ru/post/434404/

More articles:


All Articles