Anonymous_User Absent Member.
Absent Member.
288 views

InitUserName in user session events

Hi,

what are the semantics used by engineering to determine whether and, if so,
which values are put into the Init/TargetUser* fields for user session
events?

Norbert
0 Likes
2 Replies
Anonymous_User Absent Member.
Absent Member.

Re: InitUserName in user session events


This is an excellent question, as this actually gets pretty
complicated.

So basically a user session goes something like this, in general:

1) A user sits down at a terminal, and enters a set of credentials
2) Those credentials are passed to some form of authentication engine
which checks to see if they are valid, meaning whether the presented
credentials "match" a real user account in the system
3) Once the user is authenticated, meaning that we know who they are in
terms of internal user accounts, then they are authorized for access, a
session is created for them, etc
4) Next, they do some work in the system - look at files, run programs,
create other users, etc
5) Finally, they disconnect

So, the first part of this process is the most complicated. All we know
about this user at first is what credentials they presented - these
might be perfectly valid, they might be an exact representation of a
user account in the system, or they might be some alias, they might be
invalid (either intentionally or not), etc. So all we can do for
auth/session events, at first, is to display those proffered credentials
as the initiating user information, since that's all we know about that
person.
Now, if the login succeeds, that means that we successfully matched
those credentials against a real account in the target system. So in a
sense, a login is really a "matching" action, where the source is the
presented credentials, and the target of the match is the user account
that those credentials match. For that reason, for successful logins (or
failed logins that fail because of something *other* than a credential
mismatch), we present information about the matched user account in the
TargetUser* fields.
Note that this also works well for 'su' and 'Run As' behavior - the
"initiating" user takes on a set of target credentials there as well,
although we also know in that case that the initiating user account is a
"real" account, whereas for general logins all we know is what they user
typed in.
For *failed* logins, however, the situation is more complicated. If the
presented credentials didn't actually match any internal user accounts,
then in general we should present NOTHING in the TargetUser* fields. If
they matched a target user, but the password didn't work, perhaps, then
we would in general want to present the matched target account info so
that you could find out what accounts were targeted.

OK, enough about that. The rest is much easier - for all other user
activity, we know for sure which actual real user account is initiating
any given activity, so that account info will appear in InitUser*.

Note that this means that the user account information may appear to
"move" from TargetUser* to InitUser*, in a sense, after the login event.
On the other hand, if the presented credentials match exactly with the
matched internal account, then they will be the same across the board -
but if there's a user alias or something, that might not be quite the
case.

HTH


--
DCorlette
------------------------------------------------------------------------
DCorlette's Profile: http://forums.novell.com/member.php?userid=4437
View this thread: http://forums.novell.com/showthread.php?t=442340

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: InitUserName in user session events

Hi David,
I would have excepted, that when I see a login event that has an InitUser
set, then that user is actually logged in to the originating host. This
information is not provided by all event sources but e.g. Sentinel SCC and
Oracle DB do provide the OS login name of the user. So if we put the
provided username into InitUser fields on failed logins that creates a
conflict.
Another thing to mention is that e.g. the SLES collector puts the provided
username into InitUser for successful logins as well, although no
information about the user's name on the initiating system is provided by
the SSH protocol.
So rather then overloading the InitUser field with different semantics for
login events, we should always put the requested userid into the TargetUser
fields, no matter if the authentication fails or succeeds.

Norbert

>>> On 28.07.2011 at 05:06, DCorlette<DCorlette@no-mx.forums.novell.com>

wrote:

> This is an excellent question, as this actually gets pretty
> complicated.
>
> So basically a user session goes something like this, in general:
>
> 1) A user sits down at a terminal, and enters a set of credentials
> 2) Those credentials are passed to some form of authentication engine
> which checks to see if they are valid, meaning whether the presented
> credentials "match" a real user account in the system
> 3) Once the user is authenticated, meaning that we know who they are in
> terms of internal user accounts, then they are authorized for access, a
> session is created for them, etc
> 4) Next, they do some work in the system ‑ look at files, run programs,
> create other users, etc
> 5) Finally, they disconnect
>
> So, the first part of this process is the most complicated. All we know
> about this user at first is what credentials they presented ‑ these
> might be perfectly valid, they might be an exact representation of a
> user account in the system, or they might be some alias, they might be
> invalid (either intentionally or not), etc. So all we can do for
> auth/session events, at first, is to display those proffered credentials
> as the initiating user information, since that's all we know about that
> person.
> Now, if the login succeeds, that means that we successfully matched
> those credentials against a real account in the target system. So in a
> sense, a login is really a "matching" action, where the source is the
> presented credentials, and the target of the match is the user account
> that those credentials match. For that reason, for successful logins (or
> failed logins that fail because of something *other* than a credential
> mismatch), we present information about the matched user account in the
> TargetUser* fields.
> Note that this also works well for 'su' and 'Run As' behavior ‑ the
> "initiating" user takes on a set of target credentials there as well,
> although we also know in that case that the initiating user account is a
> "real" account, whereas for general logins all we know is what they user
> typed in.
> For *failed* logins, however, the situation is more complicated. If the
> presented credentials didn't actually match any internal user accounts,
> then in general we should present NOTHING in the TargetUser* fields. If
> they matched a target user, but the password didn't work, perhaps, then
> we would in general want to present the matched target account info so
> that you could find out what accounts were targeted.
>
> OK, enough about that. The rest is much easier ‑ for all other user
> activity, we know for sure which actual real user account is initiating
> any given activity, so that account info will appear in InitUser*.
>
> Note that this means that the user account information may appear to
> "move" from TargetUser* to InitUser*, in a sense, after the login event.
> On the other hand, if the presented credentials match exactly with the
> matched internal account, then they will be the same across the board ‑
> but if there's a user alias or something, that might not be quite the
> case.
>
> HTH
>




0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.