Kill logins when accessing a TCODE

[Former Member]

Experts:

Is it possible to kill an SAP login as soon as one accesses a specific transaction (say SE38)? If so, how would you go about?

<removed_by_moderator>

Thanks.

UV

Edited by: Julius Bussche on Aug 20, 2008 10:39 PM

[Former Member]

It is possible, but I would first question the requirement if I were you. Do you really need this harsh measure?

If a certain transaction (or functionality) is so insecure that you cannot protect it... then most likely the security of that functionality is the problem...

However, there may be exceptions and I won't judge your motives - there are a few cases were this can and have been used.

First of all, you need to find an appropriate exit in the coding where you can add your own coding, or worste case modify standard coding. There are some standard routines which do the same as your requirement, but those are only for "illegal" stuff (like cracking passwords) - they standardly are not for attempting to use SE38, for example...

If you can find an appropriate source code location and do some validations that the caller is really not wanted at all, then you can search here and check SAP notes relating to "call syst_logoff".

You can see an example of the usage and coding technique in SAP note 609863.

It will lock the user ID and terminate their session(s) without saving any data, and without warning.

Hope that helps you further now...

Cheers,

Julius

[Former Member]

Just like what Julius said, per me...."prevention is better than cure".

Rather than killing someone's session abruptly, not giving that access would be much nice. Restrict the tcode which you don't want users to run, which would save the programming for exits and other overheads.

Regards,

Zaheer

[WolfgangJanzen]

Well, I'm not sure what is scaring me most: the user which is attempting to do something for which he has authorizations but despite that is not supposed to perform - or the administrator which acts as a gun man seeking to "punish" his users. (Notice: "IT security" and "security guards" are two different things).

[Former Member]

> Zaheer wrote:

> ...."prevention is better than cure".

Principally yes and you have Wolfgang on your side now as well... , but I was thinking about this and whether there might be special requirements outside of the normal out-of-the-box system.

In addition to there being many transactions for this application, there might not be any transactions at all and any attempt to do anything outside of the boundaries of what the application is permitted to do... should invoke a harsh and immediate reaction toward the caller.

> Rather than killing someone's session abruptly, not giving that access would be much nice. Restrict the tcode which you don't want users to run, which would save the programming for exits and other overheads.

There might be many transactions or no transaction codes at all involved - and any transaction call what-so-ever should be blocked. Perhaps the application has the ability to do this by it's design, in which case just removing all tcodes from the authority of the user might not be enough, considering how many tcodes there are...

I like these sorts of discussions and that it is possible to do stuff like this - but I agree with you that these sorts of requirements in reality often have better possible solutions or they are an under-overkill for the risk (e.g. if the user start tcode SE38 ...).

I have often heard that the golden rule of security is => validate all input; sanitize all output.

Cheers,

Julius

[Former Member]

There you go Julius

Ya, it these things are possible, however do we need them ?

Like, if you take SCC4 and want sessions to be closed if someone executes them, then there are so many cases you have to consider

Will this response ("killing sessions") be same for all users or there must be some exception

What if you need to do that thing as a administrator ? (Hope for the best and prepare for the worst

Its a good discussion, but as Bernard pointed out, i would also like to hear from U.V.....

Good Nite !!!

Zaheer

[Former Member]

There should be some way to kill a session as what was mentioned by Julius. But a nicer way out would be

1. Lock the transaction SM01 (if it is very critical). Users would not be able to access such transactions.

2. In case if the users should not have access to certain parts of a transaction (try a variant transaction)

3. Restrict based on authorization (in case only certain users should have access to it).

ravi

[Bernhard_SAP]

....maybe UV will give us his idea standing behind his intention for this harsh action of kicking out users....

[Former Member]

Julius,

I am actually quite interested in this approach from a stand point that some users are intentionally trying to access things they know they are not allowed, such as salaries, and other HR related data. This may be harsh, but it may also stop users that have a wide knowledge base from previous jobs. Is there away to do this, but have an exception list, and possibly compile a report to tell administrators who this is locking??

Aside from locking it down by authorization, I would like to do this to find out what users are trying to access sensitive data. Any suggestions? I looked up note 609863 and it was about sys_logoff for users trying to access the wrong version of the GUI, was that an error or is that the only info SAP provides for forced system log off.

Thanks,

James

[Former Member]

Hi James,

> I am actually quite interested in this approach from a stand point that some users are intentionally trying to access things they know they are not allowed, such as salaries, and other HR related data.

From the above, you can see that the general opinion is to prevent unauthorized access. In this case, the user is not abruptly logged off, but rather an error message is raised to inform them that they don't have access or the data is simply not returned.

> This may be harsh, but it may also stop users that have a wide knowledge base from previous jobs.

Users with a wide knowledge base and the correct access is a good thing, in my opinion. If either are missing, there can be problems...

When speaking to business management people about security, I have often encountered that they are more concerned about user training and skills being the cause of system disruptions and data inconsistencies / loss, than what they are of (intentional) security hanky-panky... they do have a point to a certain extent.

But I think you are refering to something else here...

> Is there away to do this, but have an exception list, and possibly compile a report to tell administrators who this is locking??

One way of doing this is via the security audit log (SM19/SM20N/etc). Not only can you monitor who attempts to unsuccessfully use transaction PA20 (for example) but you can also check that successfull calls to HR transactions are made by users who are authorized for the transaction(s). A sure give-away is anyone who tries to start transaction PA01, PA02, PA03... (don't laugh... it has happened...). You can also monitor reports in this way (and verify authorized users for submitting known reports).

How you then react to it is up to you. A failed submit or navigation in the Easy Access menu might just have been a careless click or a "if I can do it this easily, then why not do it" attitude. You can lock them manually if you want, or write a report which does it automatically and sends emails, etc etc...

> Aside from locking it down by authorization, I would like to do this to find out what users are trying to access sensitive data. Any suggestions? I looked up note 609863 and it was about sys_logoff for users trying to access the wrong version of the GUI, was that an error or is that the only info SAP provides for forced system log off.

That is an example of using the 'syst_logoff' technique (in the specific case, to ensure that only users of a certain GUI version access the system...). You can use it for other purposes as well... however I am still a bit sceptical about this as being an overkill for any normal scenarios - in addition to the risk that you might lock everyone out unintentionally...

Cheers,

Julius

[Bernhard_SAP]

Hi James,

I am not sure about that, but I think to remember, that you can configure such alerts using RZ20 (ccms monitor templates->security->Transaction start). Using an appropriate auto reaction(SMS Alert, E-Mail to Admin) you can be alarmed as soon a user accesses your 'critical' transactions and contact the user immedately (like big brother). After some time users will know, that such actions are monitored and they will stop automatically. Pls keep in mind, that there might be legal regulations regarding user activity (monitor user activity) - a good idea is always to inform all users in advance (for instance by mail), that user activity regarding critical transactions is monitored.

Well these are just thoughts and im not sure if rz20 can cover that , but I heard about the broad possibilities of that wonderful transaction....

b.rgds, Bernhard

[Former Member]

Thanks to both for the information. I actually do use SM19 and 20 to monitor these logs, but with so many users it's has proven hard to be a useful tool outside of trouble-shooting user accounts and authorizations. The reason I ask for this is not to be harsh, but to try in inhibit pesky users from attempting to access things they shouldn't and even though they don't have authorization they shouldn't be navigating to things intentionally just to test the waters. I believe that I will try RZ20 and see how that works for me.

Thanks a bunch,

James

[Former Member]

>

> Thanks to both for the information. I actually do use SM19 and 20 to monitor these logs, but with so many users it's has proven hard to be a useful tool outside of trouble-shooting user accounts and authorizations.

What I've done before is to schedule a periodic job to search the security audit log for specific events which I know to be undesirable (for example programs who's names start with "!", or changing role authorizations in production, or any attempts what-so-ever to logon with SAP* / DDIC, etc etc).

There are some reports for this. It's not "realtime" but it saves you having to manually go through thousands of log entries (and therefore not wanting them anymore...).

Cheers,

Julius