Restricting users with MAC address

[Former Member]

Hello

We are using ECC 6.0 on Sun system with Oracle 10.2.0.2.0 DB.

My question is, to increase security I want to restrict users to logon only from their own clients not from anyone elses computer. To do that I want to assign every user name a MAC address of their computers. Also external consultants may use secondary computer so maximum number of assignable MAC address numbers must be 2.

Is there a possible way to do that?

I want to do that because we have more than 4000 active users and it is hard to keep everyones account safe. For example one user goes on vacation but did not inform administration team about that and gave his/her account to his/her collegue. So other user continues to use that user's account without our knowledge and if something bad happens that user will be in serious trouble. We want to prevent this.

If MAC address filtering cannot be implemented what other ways can we do?

[Former Member]

Hello

We are using ECC 6.0 on Sun system with Oracle 10.2.0.2.0 DB.

My question is, to increase security I want to restrict users to logon only from their own clients not from anyone elses computer. To do that I want to assign every user name a MAC address of their computers. Also external consultants may use secondary computer so maximum number of assignable MAC address numbers must be 2.

Is there a possible way to do that?

I want to do that because we have more than 4000 active users and it is hard to keep everyones account safe. For example one user goes on vacation but did not inform administration team about that and gave his/her account to his/her collegue. So other user continues to use that user's account without our knowledge and if something bad happens that user will be in serious trouble. We want to prevent this.

If MAC address filtering cannot be implemented what other ways can we do?

[JPReyes]

Thats not a standard SAP funtionality... I'll move this to the security forum they'll be able to expand on this.

Regards

Juan

[Former Member]

Your options are in SM04 via the menu: User --> Technical Info.

Other than the computer name and the host IP-address I am not aware of anything "deeper" than that. Also cannot remember ever having seen a physical address in a trace anywhere.

You can however quite easily implement a detective control for this based on the terminal name or IP-address and logging successfull logons in SM19. You could even automate it to a large extent. You can then deactivate their password until they step forward, or just give them a smack

Another usefull solution is to implement Single-Sign-On against a network directory (sometimes refered to incorrectly as "LDAP system") tied to the workstation. This makes it more painfull to hand out access to file servers, mail, all other SSO applications, etc. It also has a better survival rate than a MAC-address when someone starts a thin-client project in your company....

However, all this is probably just a symptom of a bigger security-culture problem combined with insufficient authorizations for colleagues to substitute for each other during planned or unplanned absences.

Cheers,

Julius

[Former Member]

Hello

We are already taking lots of every user action in systems but it is nearly impossible to track every user by looking every user's logs. So we have to make a permanent or at least a working solution to prevent users making abuse of using another one's account information. Searching for logs is usefull in small business systems but we have 4000+ users active on production systems.

[Former Member]

>

. Searching for logs is usefull in small business systems but we have 4000+ users active on >production systems.

My clients with 10000-20000 user manage processing the logs absolutely fine.

Restricting by MAC address has so many potential issues it really is not a good idea to mitigate a relatively small risk. If users know they are personally accountable for what happens with their ID then that is for them to make that decision.

If you want to improve non-repudiation then look into something like smart card or biometric authentication. They are not infallible but generally reduce the instances of account sharing.

[Former Member]

> but we have 4000+ users

My current system has 3 million users in SU01. A combination of SAML SSO authentication on the frontends which permits use of the same identity federated through to the backend systems, where we monitor with the SM19 / SM20N audit log.

Works fine and no need to maintain all 3 million users' MAC-addresses manually...

Cheers,

Julius

[Former Member]

The part that I didn't understand is if in your company user sharing is an accepted practice. I'd hope not, because otherwise I wonder how there's any audit trails possible: I guess your auditing software would need a tight integration with the vacation calendar, which is hopefully reliably maintained and even names the substitute - maybe along with a digital signature from the substitute, just to make sure no false accusations come up...

Basically I'd expect that user sharing is not allowed and users are trained not to do that. If users deviate from that policy they should be held responsible.

If you really would add filtering on MAC level, how long do you think it would take before you have the first cases of MAC spoofing (after all the person on vacation, who has given out his user ID, most likely also turned their PC off, so there's not even any network collisions)?

If MAC address filtering cannot be implemented what other ways can we do?

Have good security policies in place and train your users. After all, the best security concept is worthless (or maybe more accurate <i>bound to fail over time</i>) if your users are not on board.

Cheers, harald

[mvoros]

Hi,

I've already mentioned it on this forum but once again. Filtering by MAC address is not possible unless you have all computers in the same segment of local network. Usually, the SAP systems are in separate DMZ and the client PCs are in the different segment. When client wants to connect to application server the request is forwarded through routers to network segment with application server. The MAC address is replaced by MAC address of router. Hence application server sees all sessions coming from same MAC address. Just run traceroute from one client to your application server and you will see haw many hops are between them. Even if it was possible then I don't see any benefit. MAC address spoofing is pretty easy.

>

For example one user goes on vacation but did not inform administration team about that and gave his/her account to his/her collegue. So other user continues to use that user's account without our knowledge and if something bad happens that user will be in serious trouble.

A user who gives his login details to another colleagues fully deserves to be in serious troubles. I remember one poster displayed in toilets in one client. You don't share your tooth brush. So why do you share your login?

Cheers

[Former Member]

>

A user who gives his login details to another colleagues fully deserves to be in serious troubles. I remember one poster displayed in toilets in one client. You don't share your tooth brush. So why do you share your login?

They share because there not enough users in remote locations. For example one office needs 2x FI users, 2x MM users and one manager. If one MM user leaves company and other MM user goes to vacation office manager decides to operate their work himself. Because work must go on and board of directors decided to not hire many new employess but few to our company. So on remote locations managers usually permits their own users to use other user's accounts if necessary.

[Former Member]

How long does it take to set up a new account for a new employee or one how moves possitions in SAP and needs new roles?

This is often the point-of-service failure and what you have been describing is just one of the symptoms.

Others are a proliferation of desktop computing tools and RFC plug-ins, as well as implementing their own systems instead of using global systems and global processes.

Cheers,

Julius