Password synchronization?

[Former Member]

I put together a couple programs that allows users to push their password from one system/client to all clients in a list of RFC destinations. It simply takes the local USR02-BCODE value and pushes it to the remote destination, there it loops through T000 and USR02 to find the user, adjust the history, then update the uflag, ltime, pwdchgdate, and bcode. This has worked very well for BASIS members and for IDu2019s like DDIC to allow a password to be managed in one system then u201Creplicatedu201D to all the other systems and clients that the user may exist in.

This has worked well for us until the upgrade to NW70. Now it seems the field PASSCODE has come into play. Can someone explain the role of the field PASSCODE in relationship to the field BCODE. Or explain if there is something else to consider when synchronizing passwords. We have found this tool very helpful for quickly changing DDICu2019s and SAP*u2019s password when an employee or contractor leaves and we would like to continue to have this ability.

There are 3 parts to this password synchronization process. There is the prompt program that asks to the user ID to synchronize, there is a function module that is Remote-Enabled, and an include to execute the synchronization.

Please keep in mind that I am a BASIS person so this code is not the best.

Z_SYNC_PASSWORD_PROMPT

&----

---

*& *

*& Report Z_SYNC_PASSWORD_PROMPT *

*& *

&----

---

*& *

& The programs Z_SYNC_PASSWORD_PROMPT and Z_SYNC_PASSWORD_EXECUTE work

*& together to allow a user to be specified as a parameter. That *

*& user's password will be picked up from the current client and *

*& propagated to every client where it exists for each destination you *

*& specify. *

*& *

&----

---

REPORT Z_SYNC_PASSWORD_PROMPT LINE-SIZE 120 MESSAGE-ID 38 NO STANDARD PAGE HEADING.

&----

---

*&

*& Modification log

*& Date CTS Programmer Description

*& 03/09/2007 XXXXXXXXXX XXXXXX Created the program

*&

&----

---

tables: usr02, t000, rfcattrib.

data: passwd like usr02-bcode,

dest_sid(3),

desti like rfcattrib-rfcdest,

client like t000-mandt,

rc_mandt like t000-mandt,

dest like rfcattrib-rfcdest,

rc type I.

data: begin of itab occurs 10.

include structure usr22.

data: end of itab.

data: begin of itab1 occurs 10,

rfcdest type rfcdest,

end of itab1.

parameters:

user like usr02-bname obligatory default sy-uname,

p_pass like rsyst-bcode.

select-options:

scr_dest for dest no intervals obligatory matchcode object H_RFCDEST.

at selection-screen output.

loop at screen.

if screen-name = 'P_PASS'.

screen-active = '1'.

screen-input = '1'.

screen-output = '0'.

screen-invisible = '1'.

modify screen.

endif.

endloop.

start-of-selection.

&----

---

*&

*& Mainline routine

*&

&----

---

&----

---

*&

*& Get the user and their password.

*&

&----

---

select single * from usr02 where bname = user.

if sy-subrc <> 0.

write: / user, 'user does not exist!'. exit. "No template user

endif.

passwd = usr02-bcode.

perform chk_password.

if rc <> 0.

exit.

endif.

&----

---

*&

*& Change passwords in selected systems

*&

&----

---

loop at scr_dest.

desti = scr_dest-low.

dest_sid = desti.

if dest_sid = sy-sysid. "If running against the current system

client = sy-mandt. "Tell receiveing program to skip current client

else.

client = '066'. "else use 066 as the client to skip

endif.

refresh itab.

clear itab.

perform chg_desti. "RFC to desti and sync the password

commit work and wait.

endloop.

if rc = 0.

message s000 with 'Processing complete'.

endif.

&----

---

*&

*& End of Mainline routine

*&

&----

---

&----

---

*&

*& Forms

*&

&----

---

&----

---

*&

*& CHG_DESTI

*&

&----

---

*&

*& This routine calls the Z_SYNC_PASSWORD function module on remote

*& hosts.

*&

&----

---

form chg_desti.

call function 'Z_SYNC_PASSWORD' destination desti

EXPORTING

passwd_user = user

passwd_bcode = passwd

passwd_ex_mandt = client

TABLES

passwd_itab = itab

EXCEPTIONS

passwd_fail = 1

others = 2.

rc = sy-subrc.

case rc.

when '0'.

write: / 'Clients updated for', dest_sid.

loop at itab.

write: / ' ', itab-mandt.

endloop.

write: /.

when '1'.

write: / user, ' was not found in any clients on', dest_sid.

write: /.

when '2'.

write: / 'ERROR...received when trying to update', dest_sid.

write: /.

endcase.

refresh itab.

endform. "chg_desti

&----

---

*&

*& CHK_PASSWORD

*&

&----

---

*&

*& This routine is used to double check that the user knows the current

*& password of the user id being synchronized.

*&

&----

---

form chk_password.

call function 'SUSR_LOGIN_CHECK_RFC'

exporting

bname = user

password = p_pass

exceptions

user_locked = 1

user_not_active = 2

password_expired = 3

wrong_password = 4

internal_error = 5.

rc = sy-subrc.

if rc <> 0.

message i000 with 'Current password validation for ' user

'failed. Error = ' rc.

exit.

endif.

endform. "chk_password

Z_SYNC_PASSWORD

Function module

Processing Type: Remote-Enabled Module

Import:

PASSWD_USER LIKE USR02-BNAME

PASSWD_BCODE LIKE USR02-BCODE

PASSWD_EX_MANDT LIKE USR02-MANDT

Tables:

PASSWD_ITAB LIKE USR02

Exceptions:

PASSWD_FAIL

Source code:

FUNCTION Z_SYNC_PASSWORD.

*"----

---

""Local Interface:

*" IMPORTING

*" VALUE(PASSWD_USER) LIKE USR02-BNAME

*" VALUE(PASSWD_BCODE) LIKE USR02-BCODE

*" VALUE(PASSWD_EX_MANDT) LIKE USR02-MANDT

*" TABLES

*" PASSWD_ITAB STRUCTURE USR02

*" EXCEPTIONS

*" PASSWD_FAIL

*"----

---

include Z_SYNC_PASSWORD_EXECUTE.

ENDFUNCTION.

Z_SYNC_PASSWORD_EXECUTE

&----

---

*& Include Z_SYNC_PASSWORD_EXECUTE

&----

---

*&

&----

---

*& *

& The programs Z_SYNC_PASSWORD_PROMPT and Z_SYNC_PASSWORD_EXECUTE work

*& together to allow a user to be specified as a parameter. That *

*& user's password will be picked up from the current client and *

*& propagated to every client where it exists for each destination you *

*& specify. *

*& *

&----

---

*&

&----

---

*&

*& Modification log

*& Date CTS Programmer Description

*& 03/09/2007 XXXXXXXXXX XXXXXX Created the program

*&

&----

---

tables: usr02, t000.

data: user like usr02-bname,

passwd like usr02-bcode,

client like t000-mandt.

user = passwd_user.

passwd = passwd_bcode.

client = passwd_ex_mandt.

clear passwd_itab.

"if running againts current system, the current client will be skipped

"else CLIENT will be set to 066 also having no effect on the program

select * from t000 where mandt <> '066' and mandt <> client.

select * from usr02 client specified where mandt = t000-mandt and

bname = user and codvn <> 'X'.

passwd_itab-mandt = usr02-mandt.

append passwd_itab.

*& push history back one

*& 5 from 4

usr02-ocod5 = usr02-ocod4.

usr02-bcda5 = usr02-bcda4.

usr02-codv5 = usr02-codv4.

*& 4 from 3

usr02-ocod4 = usr02-ocod3.

usr02-bcda4 = usr02-bcda3.

usr02-codv4 = usr02-codv3.

*& 3 from 2

usr02-ocod3 = usr02-ocod2.

usr02-bcda3 = usr02-bcda2.

usr02-codv3 = usr02-codv2.

*& 2 from 1

usr02-ocod2 = usr02-ocod1.

usr02-bcda2 = usr02-bcda1.

usr02-codv2 = usr02-codv1.

*& 1 from current

usr02-ocod1 = usr02-bcode.

usr02-bcda1 = USR02-pwdchgdate.

usr02-codv1 = usr02-codvn.

*& set new current

usr02-bcode = passwd.

usr02-uflag = 0.

usr02-ltime = sy-uzeit.

usr02-pwdchgdate = sy-datum.

update usr02 client specified.

endselect.

endselect.

commit work and wait.

[Former Member]

> Please keep in mind that I am a BASIS person so this code is not the best.

If it works to synchronize passwords, then that is a fair statement

At the least, you should consider the consequences and warn the data / system owners about it.

It should not just be a convenience, and the source of the sync should be very secure.

What has happened now, is that the hash code for the new password hashing mechanism has a system and client specific attribute to it, so you cannot synchronize passwords accross systems by simply synchronizing the hashes. In fact, even the sysid and mandt won't help you as far as I know.

I would challenge the requirement in the first place, but if you can present a valid reason and scenario for doing this, then perhaps there is a way to do this if you are willing to accept the risk.

Cheers,

Julius

[Former Member]

You are also updating SAP tables directly. That is always a bad idea because they and the interpretation of them and their fields, change (without warning).

General bad idea...

[Former Member]

It is very helpful for the BASIS team to have a way to quickly and easily synchronize their passwords across the systems and clients within our environment. We have some 190 systems of which most are support systems with more than 1 client. Manually synchronizing or keeping track of all those passwords is nearly impossible. Prior to setting up this method with half the servers we have now it took me about 2 hours to synchronize my password. With this method, Iu2019m done in a couple minutes.

The prompt program is only available in the CUA system and only BASIS is aware or allowed to use it. When I provided the code, I removed most of the sections that perform the edits.

Of course this type of tool always has the risk of not working, like I am dealing with now. However, the benefits and time savings of having 50+ BASIS members adjusting all their passwords in minutes vs. hours every 6 weeks is worth trying to get something to work. That can be a savings of approximately 800 hours of BASIS rates per year.

I hope this explains the value of such a functionality and I would really appreciate any assistance that can be provided to help make this work.

[Former Member]

One solution is to use a "password vault" to keep the passwords in, and then only change the password whenever it is next used (and then also change it in the vault). This has an added advantage that the passwords are less likely to be the same or weak or have a potentially "crackable" password convention accross these 190 systems. There are a number of such products available. You might also want to consider a special user group for these users, such that they are not locked as easily due to inactivity in the client / system, and the auditability of who accessed and changed the password.

Another alternate way of doing this (though there are some warnings in the document) is via a [password-hook|https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/security-and-identity-management/identity-and-access-management/identity%20center%20-%20active%20directory%20password%20hook.pdf].

Cheers,

Julius

[Former Member]

Another thread which will help you is this one (). Your sync tool is not meant to work for a reason (typically sharing of user ID's and inconsistencies in SAP's USR and USH tables, such as missing change documents...). You could for a while set the downward compatability settings for the whole system such that PASSCODE is irrelevant, but the package concept will be stronger as far as I know.

My personal recommendation would be to use an individual "password vault" and not use DDIC (protected by a user group) except at upgrades. A central "password vault" can also be used, if it's own "DDIC" is secured.

Cheers,

Julius

[Former Member]

Julius,

Thank you so much for your help. I am going to see if we can adopt the approach of using the Identity Center you introduced me to or by using SSO against our LDAP. Changing to something like that or course will require an intense political effort as you might imagine. In the short term, it would be helpful to move forward with deactivating the PASSCODE. I believe the parameter login/password_downwards_compatibility will need to be set. Can you advise what the value needs to be? Iu2019m thinking it needs to be set to u20185u2019 but Iu2019m not positive.

Thank you again for all your help,

John

[Former Member]

Yes, as far as I know the value you need using that approach is '5', but have not tried this myself so there might be surprises.

Another possible and safer option (though you should check this with your license manager) would be to change the user type to 'service' (such that an intitial password no longer needs to be changed), but is still okay for your password expiry date policy (you mentioned wanting to "manually" reset the pw every 6 weeks). You could then use the standard SAP API's to BAPI a compatable password (not the hash!) to the higher release systems. This would save your tool miles of coding and not interfer with the new password rules for systems which do use it. You could "think it pretty" as a "basis service" in the system...

To be honest, I think the problem is still sharing of accounts and / or the number of systems which passwords are needed for, and the solution is a "password vault" if many passwords are required for strong authentication of many user accounts with strong access.

Cheers,

Julius

PS: I was an auditor for a while. Do you not think your auditors will notice that the hashes are the same and the change docs are missing / inconsistent and become sceptical?

[Former Member]

>

> PS: I was an auditor for a while. Do you not think your auditors will notice that the hashes are the same and the change docs are missing / inconsistent and become sceptical?

Julius, the vast majority of Auditors are not as thorough as you!

[Former Member]

Julius,

I will test the parameter set at u20185u2019 first.

In principle, I agree with what you are saying about retaining the strength of the passwords. I have been struggling to get the team to accept more appropriate approaches to generic IDu2019s like DDIC and SAP* but it is a tuff task. Also, only the BASIS members have the issue of so many passwords in so many places. If we were able to shift to SSO, that would eliminate the need to sync their passwords. The use of password vaults is in use today but it is a tuff administrative task with so many systems and so many clients. I believe my course of action for this effort will involve a couple phases. First will be to try and get the sync programs working across all the systems again. Next will be a dual effort of stopping the use of generic IDu2019s and implementing SSO or Identity Center. The latter will require my best campaigning.

I donu2019t believe the auditors, or anyone else for that matter, will know what happens at this level. BASIS is the only group that understands the integration of the systems. Everyone else thinks of the SAP systems as exclusive to their own business need, including the auditors. In fact, that is why we have ended up with so many systems.

Thank you for all your help,

John

[Former Member]

Sounds like a good plan. At least you have the named user part in place already, that is a big advantage. Of course, when using LDAP you need to be more carefull (from the SAP perspective) with the AD password management of such users.

> I donu2019t believe the auditors, or anyone else for that matter, will know what happens at this level. BASIS is the only group that understands the integration of the systems.

I was an auditor and I know some others who would look for this sort of thing. Infact, if something went seriously wrong, SAP could even cancel support for the systems. See SAP note # 7. I think even the finance auditors would notice that, who would then inform the IT auditors to go looking, if they had not seen it themselves yet.

> Everyone else thinks of the SAP systems as exclusive to their own business need, including the auditors. In fact, that is why we have ended up with so many systems.

Can't think of anything to say about that right now...

Seriously, instead of the direct table update, try tcode BAPI => Basis => Security => User => Change => Documentation. You can wrap it in your own RFC if you want to add more security, or call it on it's own.

Cheers,

Julius

[Wolfgang_Janzen]

Password synchronization (in general) is a bad idea - for the following reasons:

1. it does not scale: imagine you have about 100 systems; each time a user changes his password in one of the systems you need to notify all other 99 systems - for which all of them have to be ready to process the notification message ... (if you believe you can manage, then multiple the number by 10, ...)

2. each system implements its own (local) password policy; you'd have to decrease the password policy to the maximum common one (which will be a pretty weak one the more different systems you take into account since they'll have nearly nothing in common)

3. data replication takes time - what happens if the user is attempting to access another system before the password replication has finished ...? The more systems you need to notify the slower the entire process will be and the more likely it will happen that in the meantime such requests will be (attempted) to be processed - which however will fail and might even result in "password locked" situations ...

4. if you'd really have managed to keep the password in synch, you have to keep in mind that the number of "permissible password logon attempts" is effectively increased: once you've reached the limit on one system you can continue to try your luck on other system (knowning that the password is identical on all of them) ...

There can only be one conclusion out of that: that's not a good approach.

If a user should be able to logon with the same password on many systems then choose a SSO approach that ensures that the user really only has one single password (not replicated but validated centrally) - that password might be the same as your "network password" (-> Windows Integrated Authentication, Kerberos, SPNEGO) or a password / PIN which you need to provide in order to activate your PKI credentials (just to mention the other fraction of SSO solution providers).