Removal of Developer Key

[JaneLa]

What is the process to request that SAP remove or deactivate a Developer Key from a a specific user so that it is no longer valid or associated with that user.    Any input would be most appreciated.

Thank you, Jane Landreth

[gangadharvegi]

Hello Jane Landreth,

There is no standard procedure for removing Developer Key - If you want to limit the the User from developing remove the development(S_DEVELOP) access from user.

If you still want to remove the developer key from the system you can remove from table DEVACCESS refer to below link.

How to remove old keys of developers DEVACCESS table - Security and Identity Management - SCN Wiki

Regards,

Gangadhar

[JaneLa]

Gangadhar, if you remove the key from the DEVACCESS Table and the User who owned the Key still has developer authority, then I think that if they executed a transaction requiring a developer key, that they would be prompted to add the Key and the DEVACCESS Table would again be updated with the User ID and Key.  Do you agree?

Thank you, Jane

[Former Member]

Correct.

Authorizations for development are more important than developer keys and even system change settings in some cases.

There is no standard maintenance dialog to remove the keys. They represent a log that the key was used by the user. It is not a real risk as the keys are assigned to the installation number so a misuse can also look in the DEV system to get the key for the user name. More important than access to the key is that it was used -> you must protect that via authorizations and system settings (and code scans for programs that bypass this).

If you search for the topic DEVACCESS you will find lots of useful discussions / solutions from the past as well.

Cheers,

Julius

[Matt_Fraser]

Are you coming at this from a licensing standpoint instead of a security standpoint? After all, developer licenses are relatively expensive and most organizations have a limited number of them. If this is the case, you could remove the developer authorizations, but in order to get the license audit to stop counting the user as a developer for license purposes, you would need to remove the DEVACCESS entry (and you should also remove the developer authorizations). Additionally, you may need to go into the SSCR key administration tool on http://support.sap.com and remove the developer key there as well.

Or, if the user is gone, simply invalidate the account.

[JaneLa]

Julius, thank you for the confirmation; it was helpful.  I have been reading the posts although some are contradictory. 

If  you don't mind, I'd like to ask 2 additional questions:

1. What is the method that the ID / Developer Key associated is authenticated from the SMP to the licensed SAP application?
2. If an ID / Developer Key is deleted in the SMP, can that key still be used by the previously associated user?  Does it matter whether the key has or has not been recorded in the DEVACCESS Table?

[JaneLa]

Hi, Matt.  My interest in this topic is from the security perspective.   My understanding is that an entry is not posted to the DEVACCESS Table until the user executes a transaction requiring a key.  (If I'm wrong please correct me.)  Therefore we could have users who have keys licensed in the SMP but they have never used them (and so they aren't in the DEVACCESS Table).

So, I'd like to know from SAP, for the purpose of counting developers for license purposes, do you use:

1. The # of users with developer keys in the SMP, or
2. The # of users in the DEVACCESS Table

Thank you, Jane Landreth

[Former Member]

The authentication method is via comminication. SMP generates the key for an authorized admin and attributes are installation number and user ID, who is then displayed the key. Normally they email it to the user ID then. That user ID then enters the key when prompted for it.

There is not automation is the registration nor deactivation of keys. Deactivating the key on SMP only has a licensing implication for the number of developers you have registered. Possibly during a license audit by SAP they might complain that deactivated SMP keys for a user are not only in the DEVACCESS table (that on it's own is not a problem), but the user is also actively working as a developer (that might be a problem, from licensing perspective.

Cheers,

Julius

[gangadharvegi]

Hi Jane Landreth,

I was away from network and on Vacation on it is nice to see that discussion gone much ahead.

To my knowledge,  Developers will be counted based on the DEVACCESS table in comparison with their validity in user master record.

However in general User measurement will happened in Production and Developer access in Prod will be dependent on how Basis team build the Prod server!

If it is copy of Pristine client of development then it will contain Developers otherwise it will contain only production end users and trouble shooting team as all the users will be created from scratch and no user should be granted developer access in production.

Hope this helps!

Regards,

Ganga  

[Matt_Fraser]

Hi Jane,

Julius has it exactly right. The license audit looks at your DEVACCESS table and valid users, not what's on the SMP, but the result of the audit should really match the SMP data. From a security perspective, though, this doesn't really matter -- it's the authorizations that count. And yes, the key is not recorded into DEVACCESS until the user types in the key when the system requests it, usually the first time they execute an (authorized) activity that requires it. The audit also gets "smarter" each year, too, so if not now, then soon it probably will also look at the user's assigned authorizations.

And yes, an audit of your DEV system is generally required in addition to PRD, specifically to count those using developer keys.

Cheers,

Matt

[Former Member]

Matt Fraser wrote:

And yes, an audit of your DEV system is generally required in addition to PRD, specifically to count those using developer keys.

Shhhh..... most auditors know that systems end at the perimeter of the production client...  😉

Cheers,

Julius

[JaneLa]

Julius, thank you again for your thorough response; I sincerely appreciate it!  If I may, I'd like to delve into the topic a little more deeply.

1. When you say that the authentication method is via communication, I assume that you mean via a CPIC ID?  
2. Is the communication path from SMP to to the installation's Solution Manager?
3. Where in the SAP development client is the ID/Key/Installation # stored so that when a user is prompted to enter his key, it can be authenticated as  valid?
4. Is there a difference between deactivating and deleting a key in the SMP?  If yes, which option is best for a user who no longer requires a key?
5. If a user's key was deleted in the SMP and the user later accessed development and was prompted the 1st time to enter the key (so it could be stored in the DEVACCESS Table), would the ID/Key combination be authenticated even thought the Key no longer existed in the SMP?    If I read your response correctly, I believe that the key would still be active in the SAP client.
6. If they key was deleted in the SMP and the ID/Key was previously in the DEVACCESS Table, would the key still be valid in the SAP development client for the associated user?  If I read your response correctly, I believe that the key would still be active in the SAP client.

I'm just trying to understand the impact of deleting the key from the SMP and what actions may still be required if a user no longer requires a key.  I know that the developer authorizations need to be removed and the system/client settings must be correct.

Many thanks for your expertise!

Jane Landreth

[JaneLa]

Hi, Matt.  Thank you!   Perhaps I misread Julius' response but I thought he said that the licensing was based on the SMP.  Here's a portion of his answer:

"Deactivating the key on SMP only has a licensing implication for the number of developers you have registered."

Julius, would you mind clarifying please?

And, thank you guys for the wonderful discussion.  I appreciate it.

Jane

[Former Member]

I am not a licensing expert, but I know that it depends on the deal you have with SAP and the "normal" Netweaver license hat 5 developer keys included. So you can activate them on the SMP and deactivate old ones when people leave. If you register more keys then you probably have to pay for them. That is "invoicing" side of it.

License auditing is when SAP comes and checks your system to determine license compliance. Here they will expect that all they keys are still in DEVACCESS and additionally check to see which users with keys there are valid / unlocked in the system. That should not exceed 5 -> otherwise you might have deactivated the key on SMP but in real life it is still active in the system.

In contrast if you have an "eat as much as you want" contract with SAP, you can do as you please and there is only a security consideration -> here authorizations are much more reliable that the existence of a DEVACCESS key and you should only rely on that. Secondary control is SCC4 / SE06 settings. Third you should scan for critical ABAP statements of the workbench in Z-programs which do not make authority-checks (can happen!). 4th monitor the DEVACCESS. In this case you probably don't need to care about SMP at all (as far as I am aware, and it has no affect on security anyway).

Cheers,

Julius