Client User-Name Specification

For client host machines that support the identd service as described in RFC 1413, you can further identify the specific client requesting service by including the client’s user name in the clientSpec entry in a filter. In that case the entry has the form:

user@hostSpec

where user is the user name as returned by the client’s identd service (or a wildcard name).

Specifying client user names in a filter can be useful, but keep these caveats in mind:

• The identd service is not authentication; the client user name it returns cannot be trusted if the client system has been compromised. In general, do not use specific user names; use only the wildcard names ALL, KNOWN, or UNKNOWN.

• identd is not supported by most modern client machines and thus provides little added value in modern deployments. We are considering removal of identd support in a future version, so please inform Sun Java System if this feature is of value to your site.

• User-name lookups take time; performing lookups on all users may slow access by clients that do not support identd. Selective user-name lookups can alleviate this problem. For example, a rule like:

  serviceList: @xyzcorp.com ALL@ALL

  would match users in the domain xyzcorp.com without doing user-name lookups, but it would perform user-name lookups with all other systems.

The user-name lookup capability can in some cases help you guard against attack from unauthorized users on the client’s host. It is possible in some TCP/IP implementations, for example, for intruders to use rsh (remote shell service) to impersonate trusted client hosts. If the client host supports the ident service, you can use user-name lookups to detect such attacks.