Authentication
Authenticating clients
To access the Administration functions or any of the services you will need to have provided a username and password. For example, the username and password that KClient requires for the login window. This is checked against the host system's authentication service.
For a Windows server this will be either the local security database or, in the case of a domain or Active Directory member system, it will be checked against the domain controller's security database. The userid can be prefixed with the domain name in the usual way, e.g. accounts\gordonb.
Although KClient supports NTLM authentication, this is not supported in the Connection Manager as the NTLM security credentials have insufficient privileges. If NTLM authentication is required, then you will need to connect to a listening KCML service.
A Unix application server may use PAM (Pluggable Authentication Module) to authenticate a user. This can be configured to check the users credentials in a local /etc/passwd file, a local shadow password file or use some distributed method such as LDAP, Kerberos or RADIUS to authenticate against another security database. It can try support several such methods in turn, e.g. local first then LDAP, and can enforce checks on suitable passwords and password expiry. Some PAM implementations, e.g. Linux, support pam_smb_auth to authenticate by NTLM with a Windows or Samba domain.
Normally, authentication credentials, ie username & password, are encoded by KClient using the codepage of the current Windows locale. However, some remote password databases, such as Active Directory, may mandate all attributes to be encoded in UTF-8. In these cases, the encoding can be specified on the server in /etc/kcml/authentication.conf :
[Authentication] Encoding=utf8
Like /etc/kcml/kcml.conf this file, and its containing directories, must have secure permissions, ie: be owned by the root super-user and only have write access for the owner. Read access should be allowed for group and other. A KCML 7.09 (or later) Connection Manager will then instruct KClient (6.90 or 7.09 onwards) to encode authentication credentials accordingly.
Most PAM based LDAP authenticators will require the use of the standard RFC2307 schema when used to authenticate against an LDAP server. However this is not the default schema for Microsoft Active Directory though it is an option when installing AD on Windows 2003R2. The connection manager does have specific support for authentication with the default proprietary schema thus allowing access to existing Windows 2000 and 2003 AD installations. There are more details on how to do this here.
On installation KCML will create a default PAM configuration file specifying local security. For instance on a Linux system it will create a PAM configuration file kcc in /etc/pam.d containing entries to refer the checks to the local default authentication policy viz. system-auth.
If the the operating system does not support PAM, eg Unixware or AIX prior to version 5.3, then the user will be authenticated against the native password database, eg /etc/passwd and /etc/shadow
Limiting access
Unix versions will also check for the presence of a .kcmlLogin file in the user's home directory. Accounts which do not have this file are regarded as non-interactive, e.g. email only, accounts, and access to all of the connection manager's services will not be granted.
The Connection Manager obeys the usual Unix conventions for limiting logins. To prevent anyone, except the root user, from logging in, perhaps during system maintenance, a text file called /etc/nologin can be created. This file should contain a simple text message, for example:
System locked for software upgrade.
The Connection Manager then checks that the user name is in the Valid Users list. The IP address of the client is also checked against the list of Valid Clients. If a client is requesting to connect to a specific service, and that service defines its own access control lists, then these are checked as well. If all these checks pass access is granted. When KClient has connected and authentication fails, then a suitable error message is displayed. In the case of a failure because of a /etc/nologin file then contents of the file will be shown. 6.90 and later versions of the Connection Manager will also allow the application service to define its own nologin file, the location of which is defined by the $KCML_NOLOGIN environment variable. This variable can be set in the service's environment section so that individual services can be locked with affecting other services.