Ingres PAM Integration Documentation
From Ingres Community Wiki
Contents |
The ingvalidpam Program
The PAM (Pluggable Authentication Module) authentication environment allows applications to authenticate with alternatives to the default authentication mechanisms of a Unix or Linux platform. These alternative mechanisms, called "plug-ins", are represented by shared libraries that are dynamically loaded into the PAM module.
PAM includes an extensive set of LDAP (Lightweight Directory Access) and Kerberos mosules. The ingvalidpam program readily supports LDAP and Kerberos.
On Ingres, the ingvalidpam program can be used as a substitute for ingvalidpw. Like ingvalidpw, ingvalidpam is used only in Unix and Linux platforms. However, if your system runs its server on Linux or Unix, the platform of your Ingres clients is of no consequence. You can still use PAM to authenticate against LDAP and Kerberos environments.
The Microsoft Active Directory is one example of an authentication environment that may be supported as an LDAP or Kerberos authentication server.
Implications for Ingres
Like Ingres installation passwords, PAM releases the authentication environment from dependence on operating-system usernames and passwords on the server machine, at least for Kerberos and LDAP. However, the installation password environment still requires the process owner of the client to be recognized by Ingres. PAM removes all dependence on the operating system environment for authentication when using LDAP or Kerberos. Your client applications require only the LDAP or Kerberos username and password for authentication. As long as Ingres DBMS server recognizes the username as a valid Ingres user, your applications will still work as previously.
If you are using Active Directory or slapd authentication in your enterprise, maintenance of the authentication environment is simplified; instead of having to maintain installation passwords or operating system passwords in addition to other enterprise environments, only the Active Directory or slapd database requires updating.
One important drawback to LDAP or Kerberos authentication is that the netutil databases of the Ingres clients must be updated whenever the LDAP password environment changes. For example, if you have 100 Windows clients connecting to a Linux server using the Active Directory for authentication using "ingres" as the user name, whenever the "ingres" password is changed in the Active Directory, all 100 clients will need to have their netutil database updated with the new password. This is true regardless of whether Kerberos or LDAP is used against the Active Directory.
Prerequisites
You must have root access in order to edit the Kerberos, LDAP and PAM configuration files.
Your machine must have PAM installed. If this is not the case, you can download PAM from you Operating System vendor site; for example for Solaris see http://sun.com/software/solaris/pam. OpenLDAP is available from http://openldap.org/software/download. Kerberos is available from http://web.mit.edu/Kerberos/.
You may need to build and install PAM, Kerberos or LDAP if no binaries are available for your operating system. If your machine does not have a robust C compiler, you may need to also need to download and build gcc from http://gcc.gnu.org/releases.html. You may also need to download gmake from http://gnu.org/software/make as a prerequisite to gcc.
Source for ingvalidpam
The source for ingvalidpam executable is available in the "Build 132 - Community Edition - Source Tar (ingres-9.3.0-132-gpl-src.tgz)" for download from http://esd.ingres.com. The required .c and .h files to build the ingvalidpam executable are available in the directory ingres-9.3.0-132-gpl-src\src\cl\clf\handy_unix_win and they are:
ingvalidpam.c ingpwutil.c ingpwutil.h
Building/Configuring ingvalidpam executable
1. cc -o $II_SYSTEM/ingres/bin/ingvalidpam ingvalidpam.c inpwutil.c -lpam 2. cd $II_SYSTEM/ingres/bin 3. login as root. 4. chgrp shadow ingvalidpam 5. chmod g+s ingvalidpam 6. ingsetenv II_SHADOW_PWD <$II_SYSTEM_ingres_bin_dir>/ingvalidpam 7. Make sure the PAM configuration file named "ingres" exists in /etc/pam.d (in case of LINUX).
The sample contents of "ingres" PAM configuration file looks something like this.
#%PAM-1.0 auth sufficient pam_ldap.so auth sufficient pam_nologin.so debug account sufficient pam_ldap.so debug
Using PAM for LDAP Authentication
The LDAP module of PAM authenticates clients using the TLS (Transport Layer Security) protocol. The TLS protocol uses encrypted keys and certificates instead of cleartext usernames and passwords for authentication.
Slapd Configuration
It is assumed your LDAP environment already has a working slapd server and directory of users. Your LDAP environment must also support LDAP version 3.
The Active Directory authentication is configured nearly the same way as slapd, but a few additions.
The ldap.conf file
Client LDAP processes require reference to an ldap.conf file in order for the LDAP module to receive directions on how LDAP authentication is to be performed. In this case, the ingvalidpam program is the only client processes that references the ldap.conf file. Therefore, the ldap.conf file only needs to be configured on the server side. Client machines do not need to configure ldap.conf.
By default, ldap.conf resides in the /etc directory, but you may override the path and filename of ldap.conf with the LDAPCONF environment variable.
By default, the PAM LDAP module searches the slapd database for object classes of posixAccount. A Distinguished Name for a posixAccount user might look like this:
uid=johnDoe,ou=people,dc=myDomain,dc=com
Ultimately, in netutil, you would want to enter only the uid portion of the user name. So you define a BASE attribute of "ou=people,dc=myHost,dc=com" in ldap.conf. This shorthand allows you to define only "johnDoe" as the user name in netutil instead of the entire Distinguished Name.
The only other attribute required is the HOST, which is defined as the FQDN (Fully Qualified Domain Name) of the server as defined by TCP/IP. Therefore, your ldap.conf file would look like this:
HOST myHost.myDomain.com BASE ou=people,dc=myDomain,dc=com
NOTE: PAM expects ldap.conf to reside in /etc, and ignores the LDAPCONF variable. So if your ldap.conf directory resides elsewhere, set up a symbolic link:
ln -s /etc/openldap/ldap.conf /etc/ldap.conf
If you aren't sure what the Distinguished Names of the user database look like, the following command will list the contents of the slapd database:
ldapsearch '(objectclass=*)' -H ldap://myHost.mydomain.com:389 -b "dc=myDomain,dc=com" -x
Note that you need to know the root domain name of the slapd database, defined here as "dc=myDomain,dc=com". In many cases it corresponds to the domain and domain suffix of your host name. Ask your System Administrator if this approach doesn't work.
The Ingres PAM configuration file
The PAM component of ingvalidpam program references a service configuration file named /etc/pam.d/ingres. For PAM over LDAP, the following entries are required:
auth sufficient pam_ldap.so auth sufficient pam_nologin.so account sufficient pam_ldap.so
Note that the ldap.conf and ingres files are owned by root, but must be world-readable. Execute "chmod 644" on these files to make sure they have the correct permissions.
Active Directory Configuration
It is possible that the above configuration will work for Active Directory servers, provided that the AD server allows anonymous binds and that the authentication accounts of interest will be of type "posixAccount", or at least some type of object with a "uid" attribute. By default, the PAM LDAP module binds anonymously and looks for login attributes of type "uid".
Often, Active Directory servers do not allow anonymous binding, and the object classes of the user database do not include "posixAccount". So, the ldap.conf file needs to include a user name and password for binding purposes, and must include a directive to look for some attribute other than "uid".
Addition of these entries will allow ingvalidpam to authenticate against the Active Directory, assuming they have the login attribute sAMAccountName:
binddn CN=proxySearch,OU=myCity,OU=USA,OU=Americas,DC=myDomain,DC=com bindpw mySecretPassword pam_login_attribute sAMAccountName
Since the bind domain and password are presented in cleartext in a world-readable file, the user "proxySearch" was created to perform the Active Directory lookup. The permissions on "proxySearch" can be set so that the "proxySearch" user can do little else than search the Active Directory. You can use your own user name and password for testing purposes.
It may be necessary to browse the Active Directory database in order to find the format of Distinguished Names. To browse the Active Directory database, issue the follwing command:
ldapsearch -V -Y DIGEST-MD5 -H ldap://myHost.myDomain.com:389 '(objectclass=*)'
You will be prompted for a password. You can enter the password of your own Active Directory account. The ldapsarch command lists all of the contents of the Active Directory database. The "objectclass" filter can be specified without wildcards if a complete dump is not desired.
The following ldapsearch command allows one to browse the AD for user "johnDoe@myDomain.com" with a sAMAccountName of "johnDoe" and can serve as a test of the ldap.conf configuration:
ldapsearch -x -W -D "johnDoe@myDomain.com" -LLL "(sAMAccountName=johnDoe)"
Using PAM for Kerberos Authentication
If your enterprise has no access to an Active Directory, you must configure and populate a Kerberos KDC (Key Distribution Center). See http://web.mit.edu/Kerberos for details of downloading and configuring the Open Source version of Kerberos. The MIT site is also useful for documentation on the configuration of Kerberos if your platform (including VMS) already has a Kerberos installation.
ingvalidpam versus the Ingres Kerberos Driver
Use of PAM with Kerberos can be considered to be less secure than the Ingres Kerberos driver. In the Kerberos driver environment, the process running the application must be recognized as a valid Kerberos principal and be pre-autheticated with Kerberos tickets. In the Kerberos driver environment, the netutil database requires no username and passwords for Kerberos connection targets. In the ingvalidpam environment, it is necessary to specify the Kerberos username and password in the netutil database. The process owner does not need to be pre-authenticated via Kerberos, and does not have to be recognized as a valid Kerberos principal.
To sum up, the ingvalidpam environment uses Kerberos as a mere alternative to operating-system usernames and passwords. The Ingres Kerberos driver is considered to be a more complete approach to Kerberos.
The krb5.conf file
The krb5.conf file tells Kerberos clients where the Kerberos server is on the network. On Unix and Linux machines, usually krb5.conf resides on /etc and on VMS, it resides on KRB$ROOT:[ETC].
The following krb5.conf file contains the minimum configuration for a Kerberos or Active Directory server on myHost.myDomain.com:
[libdefaults]
default_realm = MYDOMAIN.COM
[realms]
INGRES.PRV = {
kdc = MYHOST.MYDOMAIN.COM
admin_server = MYHOST.MYDOMAIN.COM
}
[domain_realm]
myDomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
Note that the Kerberos realm defined by MYDOMAIN.COM happens to be the same as the network domain name and extension. However, the realm does not have to be named this way.
The Ingres PAM configuration file for Kerberos
The contents of the Ingres PAM file are very similar to the LDAP configuration, except Kerberos libraries are substituted for the LDAP libraries:
auth sufficient pam_krb5.so auth sufficient pam_nologin.so account sufficient pam_krb5.so
Note that the krb5.conf and ingres files are owned by root, but must be world-readable. Execute "chmod 644" on these files to make sure they have the correct permissions.
The above configuration will work equally well for Active Directory and Kerberos KDC servers.
Netutil Configuration
Now that you have the appropriate mechanism configured, you can convert your clients to use the usernames and passwords for ingvalidpam instead of the system or installation passwords.
First, make sure that II_SHADOW_PWD is defined as $II_SYSTEM/ingres/bin/ingvalidpam via the ingprenv command. If not, re-define II_SHADOW_PWD and then stop and restart the Name Server.
You can then add user names and passwords appropriate to the authentication method in the netutil database. The netutil entries for the Active Directory will be the same for LDAP as they were for Kerberos.
The Name Server will then use ingvalidpam to authenticate using LDAP or Kerberos.
If you have problems connecting, you can use the II_INGVALIDPW_LOG environment variable to troubleshoot. Here is the procedure:
- ingstop -iigcn
- ingsetenv II_INGVALIDPW_LOG /tmp/ingvalidpam.log
- ingstart
The results of ingvalidpam will be listed in /tmp/ingvalidpam.log (or whatever path/file you define).
Remember to turn off logging via "ingunset II_INGVALIDPWD_LOG" after you have finished testing!
