proxyuser Database

proxyuser entities have the following required items:

• name

Including two basic types:

SIMPLE or GROUP

Often, you do not have to enter the type specifier, as the configuration editor usually infers the type from the other items presented.

proxyuser items that are allowed in (and imply) SIMPLE:

• AUTH_USER_NAME=auth-user-name binds the proxyuser to an authuser entity. This then implies the requirement to authenticate using the methods and passwords specified for the latter.

• BACKEND_USER_NAME=backend-user-string is the string passed to a backend server by proxies as the name of the user on that server. If this item is missing, the name of the entity is supplied to the backend server.

• RADIUS is a special entry that you generally do not type.

proxyuser items that are allowed in (and imply) a GROUP:

MEMBER_NAME=proxy_user_name is repeated for each member of a GROUP.

MEMBER_NAME is not often used directly for the add verb, in favor of the addmember and deletemember verbs.

proxyuser items are allowed in either SIMPLE or GROUP:

DESCRIPTION=desc-string

proxyuser example -- the anonymous entity:

edit> proxyuser add anonymous BACKEND_USER_NAME=anonymous 
edit> proxyuser print anonymous "anonymous" ENABLED SIMPLE
BACKEND_USER_NAME="anonymous" 

This entity requires no authentication in any rule where it is included. Access is allowed by mentioning the name anonymous.

There is nothing special, within the SunScreen EFS 3.0 authentication subsystem at least, about the name anonymous; the FTP protocol assigns special meaning, but the authentication logic is unaware of this.

proxyuser items provide a means by which non-well-known but un-authenticated access can be granted.

For example:

edit> proxyuser add backdoor SIMPLE

By mentioning the user backdoor, access is granted.

proxyuser example, authenticated user entity:

edit> proxyuser add ronco AUTH_USER_NAME=ron.popeiledit> proxyuser print ronco "ronco" ENABLED SIMPLE
AUTH_USER_NAME="ron.popeil" 

The BACKEND_USER_NAME defaults to "ronco" when used.

proxyuser example, authenticated user entity with alternate backend name mapping:

edit> proxyuser add msd-root AUTH_USER_NAME=marc.dye BACKEND_USER_NAME=root DESCRIPTION="map msd to root"edit> proxyuser print msd-root "msd-root" ENABLED SIMPLE AUTH_USER_NAME="marc.dye" BACKEND_USER_NAME="root"
DESCRIPTION="map msd to root" 

Output of print is actually a single, long line.

The backend server supplies the user name "root" upon connection establishment.

proxyuser example, creation of a GROUP:

edit> proxyuser add crow SIMPLEedit> proxyuser add servo AUTH_USER_NAME=tom.servoedit> proxyuser add inbound-ftp-users GROUP DESCRIPTION="users allowed inbound access as themselves" edit> proxyuser addmember inbound-ftp-users crowedit> proxyuser addmember inbound-ftp-users servoedit> proxyuser print "anonymous" ENABLED SIMPLE
BACKEND_USER_NAME="anonymous" 

"crow" ENABLED SIMPLE 

"inbound-ftp-users" ENABLED GROUP MEMBER_NAME="crow" MEMBER_NAME="servo"
DESCRIPTION="users allowed inbound access as themselves" 

"radius" ENABLED RADIUS SIMPLE 

"servo" ENABLED SIMPLE AUTH_USER_NAME="tom.servo" 

An FTP proxy rule, which uses GROUP inbound-ftp-users, allows the user crow without a password, and the user servo with whatever authentication the authuser entity tom.servo specifies. In both instances, the name of the proxyuser entity matched is supplied to the backend FTP server.

proxyuser example, more complete, allowing RADIUS authentication and groups within groups:

edit> authuser add dilbert SECURID={ wiseguy } DESCRIPTION="contract engineer"edit> authuser add dogbert PASSWORD={ trusted } DESCRIPTION="management consultant"edit> authuser print "dilbert" ENABLED SECURID={
"wiseguy" ENABLED } DESCRIPTION="contract engineer" 

"dogbert" ENABLED PASSWORD={ "" CRYPT_PASSWORD="O6JeSCIwq0LvA" ENABLED
} DESCRIPTION="management consultant"

edit> proxyuser add dilbert AUTH_USER_NAME=dilbert BACKEND_USER_NAME=guestengr1 DESCRIPTION="contractor mapped to a guestengr"edit> proxyuser add dogbert AUTH_USER_NAME=dogbertedit> proxyuser add engg GROUPedit> proxyuser addmember engg dilbertedit> proxyuser addmember engg radiusedit> proxyuser add inbound GROUPedit> proxyuser addmember inbound dogbertedit> proxyuser addmember inbound enggedit> proxyuser print "dilbert" ENABLED SIMPLE
AUTH_USER_NAME="dilbert" BACKEND_USER_NAME="guestengr1" DESCRIPTION="contractor
mapped to a guestengr" 

"dogbert" ENABLED SIMPLE AUTH_USER_NAME="dogbert" 

"engg" ENABLED GROUP MEMBER_NAME="dilbert" MEMBER_NAME="radius" 

"inbound" ENABLED GROUP MEMBER_NAME="dogbert" MEMBER_NAME="engg" 

"radius" ENABLED RADIUS SIMPLE

Examine the way in which the FTP proxy allows access for "inbound":

user prompt: dilbert@server user passwd: sidpass@srvpass

Assuming sidpass validates "wiseguy" with SecurID:

Proxy supplies the user "guestengr1" password srvpass

user prompt: /radius/msd@server user passwd: radpass@srvpass

Assuming sidpass validates "msd" with RADIUS:

Proxy supplies the user "msd" password srvpass

user prompt: dogbert@server user passwd: trusted@srvpass

Proxy supplies the user "dogbert" password srvpass

References to non-existent user entities behave as if the entity existed but was DISABLED ( virtual ); DISABLED entities (either real or virtual) always behave so as to cause a non-terminal failure of processing.

For example:

• If a rule references a proxyuser that does not exist or is DISABLED, that rule is never matched.

• If a proxyuser group references a non-existent proxyuser entity, it behaves as if that reference did not exist.

• If a proxyuser references a non-existent authuser entity, it behaves as if it existed but was DISABLED.

Authentication logic used within the proxies is performed with a three-step check for a given user username and password passstrings:

1. If username begins with a method prefix (for example. /radius/), then that method is invoked, returning SUCCESS or FAILURE. Otherwise, username is used as the pname sought in the next check (2).

2. An ENABLED proxyuser pname is sought; if it exists. Then, if that proxyuser contains no AUTH_USER_NAME item, then authentication SUCCEEDS immediately (pass is not checked); otherwise, the value of that item is used as the aname sought in the next check (3), otherwise, pname is used as the aname sought in the next check (3),

3. An ENABLED authuser aname is sought; if it exists. Then if pass authenticates it, then authentication SUCCEEDS, otherwise authentication FAILS.

Currently, authentication logic used for Screen administrative access control uses only the third (3) stage of the logic given above (that is, no external method nor proxyuser matching is performed).

The user-portion of the rule-matching logic used by the proxies performs the three-step authentication given above. If that authentication fails, no rule match is attempted; otherwise, the is-member portion of the rule match is performed. Each rule references a proxyuser user ruser; ruser can be a GROUP or a SIMPLE user.

If username begins with a method prefix (for example, /radius/), then if ruser has an ENABLED member with method (for example, RADIUS) then is-member SUCCEEDS; otherwise, is-member FAILS. Otherwise, if ruser has an ENABLED member named username, then is-member SUCCEEDS; otherwise, is-member FAILS.