How to Improve System Security?

This article will also refer to the slogans, but already more indirectly and in a broader spectrum.

We will consider how improving system security related to logging can help administrators.
After all, admins deserve a bit of a breather doing their hard and responsible jobs, right?

Dear administrators, we want to help.

Why are we losing access to the system?

CapsLock... one example that causes us to lose access to the system.
Those who have never been wrong in this way should be the first to apply for a raise.

But where is the security here? After all, someone just made a mistake.

Well, here that the system doesn't give a damn and treats an honest, non-fraudulent user just like a burglar and lumps them together.

Do you want to break in? STOP!

Don't know how to log in? You can nab 😉 STOP!

To limit the number of invalid logins we set 'login/fails_to_user_lock' For example, to the value of 3.
Each time we log in incorrectly the counter of incorrect logins increases by one, up to the limit value, in this case 3.

The account is then blocked.

We can be unlocked by the administrator, or the system itself thanks to the parameter 'login/failed_user_auto_unlock'.

Setting the mentioned parameter to 1 causes the lock to remain only for the day on which the locking occurred.

However, be careful not to "get ricocheted", as the burglar will also have the opportunity to try to log in the next day.
With help then comes Security Audit Log.

Those who don't check SAL are on the lookout.

What is the lifespan of passwords?

That's right. Passwords have a lifespan, and by default that lifespan is as long as the life of the system, unless the user decides on his own initiative to change the password.

Looking at the issue from the point of view of system security not changing at all unacceptable.

Passwords should be regularly changed (relatively often).

But don't go to extremes and mistreat users with daily changes (unless internal security policy says otherwise).

How do we make users happy so that they live with the knowledge that their accounts are safe?

Establish the parameter 'login/password_expiration_time'. The value assigned to the parameter will indicate the number of days after which the user will be had to change the password since he established the last one.

When a user gets a new account or asks an administrator to change the password on an existing account, the administrator assigns an initial password to the account.
This type of passwords also has a lifespan and, as above, the default is as long as the system lives. When a user logs into an account with an initial password, he changes it to a password known only to himself.
This means that the sooner the user changes the initial password the better and more secure it is.

How to force a change in the initial password?

Simple. Another parameter 'login/password_max_idle_initial'.

The value of the parameter, is the number of days given to the user when he has time to change. If he fails to do so, then klops, the account is blocked.

One more interesting parameter is worth adding: 'login/password_max_idle_productive'.

Its value indicates the number of days after which the production password (established by the user) will be invalidated when not in use.

Not working? BAN.

Jak wygląda kwestia logowania?

Login. User and password. Fire. Performing duties on the system. Logout. End. Home.

Everything is fine, right? True, if it's one user and one account.

What if two users use the same account and log on to the same mandate (customer) in the system at the same time?

Such a situation is already unfortunately - undesirable. Why? Well, because this is about money, about licenses.
How many users, so many licenses. How many licenses, so much money for the software developer.
Willing or unwilling, it must be watched, such a business.

In order not to tell users: "Hey, remember: log in prudently, or else SAP will kick us in the... pockets", we establish a parameter 'login/disable_multi_gui_login' at 1 (in words: one). The matter is settled.

Let's mention that we are talking about production here.

W unique i controlled circumstances, you can allow users to log in multiple times through the parameter 'login/multi_login_users'.
As values, we specify the names of accounts (users) in the system that will be allowed to "break" the multiple login rule.

For sleepyheads or those who stand in the kitchen for coffee, it can work 'rdisp/gui_auto_logout',
will make room for those who are willing to work.

SUMMARY

Some know, others don't. Some benefit, others don't. Knowing that information is the key to... many things, let's try not to hint too much. Especially to those who don't need to or shouldn't know too much.

What are they talking about?

About a simple parameter, but how pleasant 'login/show_detailed_errors'. Set to 0 (zero), of course.

That would be it.

Remember: whoever implements security in the organization can safely sleep on assignment.