PAM NCP authentification module

the $HOME/.nwclient file:

Historically, ncpfs utilities that require login/password against a server will search for personnal information missing from the command line in a ~/.nwclient file with the following format:

SERVER1/user1	password1
SERVER2/user2	password2
...

EURINSA/bjarno

[Requester]
Default Tree Name=INSA_ROOT
Default Name Context=PC

This file may be created in user's home directory and contains 18 NDS_* values fetched by the PAM module.Its initial purpose was to facilitate the writing of the Zenux Scripts . Contributors have provided us with many examples of usage in "regular shell scripts" used during the session.

Here are the expected values of the 18 variables:

NDS_USER=flardet
NDS_GECOS="Florie Anne Lydie Lardet"
NDS_SHELL=/bin/bash
NDS_HOME=/cipc/eurinsa/2210126
NDS_UID=14694
NDS_GID=100
NDS_QFLAG=2033
NDS_HOME_SERVER=EURINSA
NDS_HOME_VOLUME=APPS
NDS_HOME_PATH=HOME/03/2210126
NDS_HOME_MNT_PNT=/mnt/ncp/flardet/nwhome
NDS_EMAIL=florie.lardet@insa-lyon.fr
NDS_EMAIL=florie.lardet@insa-lyon.fr
NDS_PREFERRED_SERVER=EURINSA
NDS_PREFERRED_TREE=INSA_ROOT
NDS_PREFERRED_NAME_CTX=PC
NDS_IS_NEW_USER=0
NDS_ZEN_FLAG=0xfc0c7101
NDS_BCAST=0

• Note that the NDS_PREFERRED_SERVER is the value of the NDS property Message Server, if present. It may not be the name of the server that authenticated the user.
• The NDS_PREFERRED_TREE is the tree in which the server that authenticated the current user resides. It is empty in Netware 3.x networks.
• The NDS_PREFERRED_NAME_CTX is the context when this user resides (the context part of its FQDN); it may be different of the authenticating server context.

Zenux Scripts (aka zenscripts):

Zenux scripts are shell scripts that will be automatically executed at session opening and session closing. You may consider them as rough Unix equivalent of Login Scripts for Dos /Windows clients. The major difference is that they are stored on every Linux client; currently they must be named zenscriptx (x=[0..5]) and be in /usr/local/bin.

• The full path to the current Unix user home ( e.g /home/alexis)
• The name of the Nwinfos file ( normally .nwinfos)

So a Zenux script should source $1/$2 to get all information read from NDS at the authentication stage. This file is overwritten as every login, so it should contains (almost) up-to-date information.

See this page for examples of zencripts

Requirements:

• The pam_auth_nds.so library is compiled and installed in /lib/security with current release of ncpfs
• With recent kernels (>2.3), ncpfs is normally configured with all required settings.
• With less recent kernel, you may have to :

  Recompile the kernel with the option CONFIG_NCPFS_MOUNT_SUBDIR (Allow mounting of volume subdirectories). So it will be possible to mount in ~/nwhome the real path to the Netware users home; some equivalent of the "MAP ROOT" command in Dos/Windows clients. Otherwise, the PAM module will only mount the Netware volume where the home is located (says USERS) and the current user will have to browse to his home (says ~/.nwhome/USERS/home/testuser) .

  While you are at it, turn on the CONFIG_NCPFS_NDS_DOMAINS ('NDS interserver authentication support') flag, that allows the private authentication data to be stored in kernel, to be shared by multiple connections to Netware.
  If needed, activate these flags in /usr/src/linux/fs/ncpfs/Config.in as below, and recompile your kernel.

  # NCP Filesystem configuration
  
  bool     '   Packet signatures' CONFIG_NCPFS_PACKET_SIGNING
  bool     '   Proprietary file locking' CONFIG_NCPFS_IOCTL_LOCKING
  bool     '   Clear remove/delete inhibit when needed' CONFIG_NCPFS_STRONG
  bool     '   Use NFS namespace if available' CONFIG_NCPFS_NFS_NS
  bool     '   Use LONG (OS/2) namespace if available' CONFIG_NCPFS_OS2_NS
  if ["$CONFIG_NCPFS_OS2_NS" = "y" ]; then
   	bool   '      Lowercase DOS filenames' CONFIG_NCPFS_SMALLDOS
  fi
  bool     '   Allow mounting of volume subdirectories' CONFIG_NCPFS_MOUNT_SUBDIR
  bool     '   NDS interserver authentication support' CONFIG_NCPFS_NDS_DOMAINS
  bool     '   Use Native Language Support' CONFIG_NCPFS_NLS
  bool     '   Enable symbolic links and execute flags' CONFIG_NCPFS_EXTRAS
  
  

Usage:

• you must insert lines calling /lib/security/pam_ncp_auth.so in auth, session and eventually password sections of the appropriate files located in /etc/pam.d.

  Say you want to make services login, kde and samba able to authentify against NDS, you must edit files /etc/pam.d/login, /etc/pam.d/kde and /etc/pam.d/samba.

  With some distributions, such as Redhat, all files in /etc/pam.d actually "call" a commun file /etc/pam.d/system-auth, so modifications to this file will make all PAM aware services ncpfs aware too. Nice ;-)

  As usual in pam's file the line must have the following format :

  #service name	service level	library called	command line options
  [auth|password|session](*)	[sufficient|required|optional]	/lib/security/pam_ncp_auth.so	options

  (*) Currently we do not process the 'account' service.

  There are quite few possible variations in "stacking" pam modules in these files. We experimented with quite a lot, and here are some guidelines to help you:

• the pam_unix module (local database) should be called first and marked 'sufficient' in the auth service.
• the pam_ncp_auth should be called last in the auth service and marked 'required'.
• Currently we do not use the 'password' service . We prefer our students to use graphical passwords changing utilities rather than typing passwd in a shell window.
• The pam_ncp_auth module can be either marked as 'optional' or 'sufficient' in the session service, but should be called last.
• the 'usual' use_first_pass or try_first_pass arguments are not needed and are ignored by the pam_ncp module.
• Command lines arguments are only needed in the 'auth' and 'passwd' services. With the 'session' service the pam_ncp module will collect from PAM internal data all the arguments of the 'auth' service.
• During tests, you should turn on debugging (-d option) and monitor content of /var/log/secure file. pam_ncp is quite talkative in this mode.

  You will find here our current /etc/pam.d/system-auth file that stacks up local, LDAP and finally pam_ncp.

  Command lines options

  The pam_ncp_auth module recognizes three options that specify the authentification methods and (too) many switches that tune up its behavior.

  1. tree= option
     Syntax: tree=TREE_NAME[:list of contexts][/ControlGroup] where:
     • Tree name= name of the Tree
     • list of contexts= a comma separated list on NDS contexts to search for the user's common name (CN) typed as Unix login
     • if absent, the module will try a contextless login by first searching all contexts where a user with that CN exists and will try in sequence CN.ctx1, CN.ctx2 ...
     • ControlGroup: a typeless fully qualified (with contexts) group name. Login will be granted if login/password match and if user is member of that NDS group.

       In the event of several users having the same CN in different contexts (either provided in the list of contexts or found by searching NDS), the module will use the password to decide. If the password mismatch, it will keep trying with other possible CN.ctx, if any.

     examples:

     tree=insa_root 				anyone in any context that has the typed-in CN may get in with the proper password
     tree=insa_root/linuxok.pc		same but only if member of group linuxok.pc
     tree=insa_root:PC,GCP.PC		search for CN only in contexts PC and GCP.PC
     tree=insa_root:PC,GCP.PC/linuxok.PC	same but only if member of group linuxok.pc
     

     Currently, only one control group is supported

     This option can be, (but should not) be repeated.. do you want to login to several trees ?

     You should be aware of two issues:

     • If one day an user types in his login in uppercase, NDS authentification will succeed, since NDS is case unsensitive, but searching the local database for this user will likely fails. So the module may try to autocreate a new user with an uppercase login and likely fails because it will find that the (NDS sent) Unix ID is used (for the same username with a lowercase login). Login will be rejected.

     • You should use the context searching feature and avoid typing relative name such as 'me.ctx' at the Linux prompt. Otherwise this module will try to create a new user with login 'me.ctx'...

     • NDS alias objects are supported. So if you have some users in contexts not listed or not searched by this module, you may create for them an alias object in one of the PAM module contexts.

  2. ndsserver= option
     This option was devised for networks were the nearest server has no replica. In that case, current ncpfs API functions cannot authenticate.
     ServerName will be the name of a server with a replica (at least read-only).
     As with the tree option, a list of contexts to search or contexless login , and the control group is supported.

     This option may be repeated to "interrogate" in sequence several servers of the network.

  3. server=option
     This syntax is deprecated and should be only used against Netware 3.x servers.

     Two syntaxes are possible and may be repeated: "server=ServerName" or "server=ServerName/GroupName".

     If you are using variant "server=ServerName/GroupName", and server is a NDS server GroupName must be fully distinguished name of Group and ServerName must be a NDS server with bindery emulation activated on every user's context.

     If server if a bindery server, GroupName must be a simple bindery group name, that is without any context specification.
     In any case, only users belonging to the group GroupName will be allow to log-in.

     Note that currently, the behavior of the module is undefined if you try to mix server=, ndsserver= or tree= options.

  4. switches:

     As usual, switches are a single letter with a '-'. With switches that accept arguments, do not put any space between the letter and the arguments.

     -a	allow "automagic " creation of accounts that have passed the Netware authentication step, by calling adduser with the appropriate parameters got from NDS. This flag should be on even if local database is in sync with NDS (using our sync script or our nss_ncp switch library (see TODO)
     -A	Spawn ncpmount with -A and -S argument, thus allowing automounting of Netware homes in a pure Netware IP environnment. Automounting must be 'on' (-zA)
     -b	Force bindery login against all servers specified in the command line with option server= . Some Netware properties will be read from server's bindery (Full Name, Group memberShip, Netware Home...) but all NDS Unix properties are unavailable (including zenflags). So in this mode, zenflags must be turned on/off by a -z/-Z switch, and IDS should be prepared in advance in local database to have some consistencies between workstations. Ignored against tree= or ndsserver=
     -d	turn on debugging output (this will really fill /var/log/secure)
     -gMIN,MAX,CFLAGS	parameters for group creation (see below).
     -l	A required flag if user's home are on NFS remote shares and if you want automounting of Netware homes. This issue has been already discussed in several occasions (ncplogin,ncpmap...). See the FAQ
     -L	Introduced in ncpfs-2.2.3. Bypass service checking table for remote access (controlled by zenflags FHRSTX) If present, all remote access will be granted if login/password match.
     -mDir_Name	By default, automounting of the current user Netware home directory will be done in a local directory named nwhome ($HOME/nwhome or /mnt/ncp/$USER/nwhome depending of -l switch) . If for some reason this does not suit you, you can change the nwhome by any other name using this option. In any case, this directory will be created if absent, with 700 directory rights granted to user being authenticated. example : -mnovell home will be in /home/user/novell or /mnt/ncp/user/novell Feature (that may not last) : with -m with no argument, the user's Netware home will be used as his Linux home . See the FAQ ;-)
     -n	Do not autocreate user's home in the local file system. This is required if user's home are on some remote NFS shares. Local workstation should have the home directory path received from NDS permanently mounted in /etc/fstab or accessible via the automount system. See the Tips and tricks for our current implementation. Login will be refused if that home directory cannot be located or has the wrong permissions. Check /var/log/secure in debug mode.
     -q	quiet mode. deprecated as -v switch. Do not use -d flag instead.
     -s	With bindery login (server=) or -b, disallow SUPERVISOR from logging-in With NDS servers, disallow admin from logging
     -S	With bindery login (server=) or -b, disallow SUPERVISOR equivalent from logging-in With NDS servers, disallow admin equivalent from logging
     -uMIN,MAX,CFLAGS,MFLAGS	parameters for user creation (see below).
     -v	Verbose mode. Deprecated. use -d instead
     -zXXXX	Add the XXXX Zenux Flags to any values read from NDS Quite useful in NW 3.X networks
     -Z	-Z Turn off all Zenux Flags processing of this station -ZXXX Turn off only specified Zenux Flags processing of this station (example : -ZT no telnet/ssh for NDS users here).

     Users creation and modification:

     syntax :-uMIN,MAX,CFLAGS,MFLAGS . Any of the four fields may be empty

     Username searched in the local database will be exactly what has been typed as login at the Unix prompt. For consistency, it should always be the same as the NDS property (CN) or Bindery property (LOGIN) in lowercase . If not found, this module will try to autocreate the local account if the -a switch is present or if the CFLAGS field is not empty.
     User creation's mode is controled by the content of the CFLAGS that can consist of one or more letters:

     r	(NDS required) When creating user, his uid must be read from UNIX:UID property, or equivalent U:nnnn L string, or LINUX:UID property. If not found or already locally used, login is not allowed and an error message is added to /var/log/secure file. Any value in fields MIN or MAX is ignored.
     p	(NDS preferred) When creating user, prefer uid from NDS. If present, the above rule will apply; otherwise new user unique uid generation method will depend of the next letter: n : (Next) When inventing uid for new user, take one which is one greater than highest used uid in MIN,MAX range. f : (First) When inventing uid for new user, take first unused in MIN,MAX range. This is the default .
     n or f	(NDS none) If the CFLAGS does not start by 'r' or 'p', user creation will use the "First" or the "Next" method above depending of the first letter (n or f). feature: Currently if CFLAGS does no start with r ou p, or is empty, all user's NDS data ( IDS, home, groups, zenflags...) will be fetched only if the -a switch is present.

     If you specify both 'r' and 'p', or both 'n' and 'f', behavior is undefined.

     By default, that is if no -u switch, new user creation will be as First unused uid rule, between 1000 and 60000 that is as if -u1000,60000,f has been used on the command line; but; please note that NDS will not be searched at subsequent logins So many features of this module will be disabled. In short, with current version you should have at least -u,,p,s on the command line.

     At every login, local user's data may be modified to stay in sync with NDS by a non-empty MFLAGS in -u switch.

     MFLAGS can consist of one or more following letters, in any order:

     • g : Update user's primary gid according to NDS database.
     • c : Update user's gecos (comment,full name) according to NDS database.
     • d : Update user's home directory according to NDS database.
     • s : Update user's shell according to NDS database.

     Note that modification of the user's login name or Unix id is not supported.

     Group membership addition is also synchronized with NDS; at user's creation, all its NDS groups will be created locally if absent (see the next section) and user's name added to them in local /etc/group. Internally the pam_ncp module spawns the usermod command with appropriate parameters.

     At every login, if the MFLAGS is not empty (any single letter g,c,d,s will suffice), NDS will be read and if user belongs to some new groups they will be added as above.

     Group membership removal is not synchronized between NDS and the local database; that is, if a NDS user is removed from a NDS group, he will not be removed at next login from the corresponding line in the local /etc/group file.

     Further efforts in this direction does not seem to be worthwhile; these flags and features will disappear if the nss library get finalized.

     Some examples:
     

     -u,,p	Testing settings: IDs may be in NDS, otherwise use default 'First unused' between 1000 and 60000
     -u,,p,gcds	Testing settings: IDs may be in NDS, otherwise use default 'First unused' between 1000 and 60000 At each login keep everything in sync with NDS.
     -u,,pn,gcds	Testing settings: IDs may be in NDS, otherwise use 'Next unused'method between 1000 and 60000 At each login keep everything in sync with NDS.
     -u20000,,p,gcds	Testing settings: IDs may be in NDS, otherwise use default 'First unused' between 20000 and 60000 At each login keep everything in sync with NDS.
     -u20000,50000,p,gcds	Testing settings: IDs may be in NDS, otherwise use default 'First unused' between 20000 and 50000 At each login keep everything in sync with NDS.
     -u,,r,gcds	Final production settings: IDs are NDS required to make sure they are unique and in sync with those used in NFS home's servers.

     Groups creation:

     syntax :-gMIN,MAX,CFLAGS

     Local Unix groups automatic creation can happen under different circumstances and unique group ids are controlled by the -g switch.

     When a new user is created in Unix, and if the authenticating server is a NDS server, all the NDS groups he belongs to will be automatically created on the local Unix station.

     The name of the Unix group will be invented from the NDS group name by removing the context part, spaces are replaced by '_' and by adding a Z if the first character of the group name is a digit. All other characters will be 'constrained' in the A-Z range.

     As and example, if user john_doe belongs to NDS groups "everyone.somecontext" and "2 nd class.someothercontext", the two groups "everyone" and "Z_2nd_class" will be created, if missing in the local Unix station.

     If this conversion does not suit you, you must specify an Unix group name using the accompanying snapin in the group's PAM ncp authentication page or add a N:UnixName string to its L (Location) strings in the group Identification page.

     As an example, if you want that members of NDS group everyone.myOu.myO be registered to Unix group users, with GID 100, you must set under NWAdmin the PAM ncp authentication values of this group to Unix Gid=100 and Unix Name=users; or alternatively set one of the L strings of everyone.myOu.myO to G:100 and another one to N:users.

     In addition, if the user has one or several some O:group_name strings in his NDS L strings property, these groups will also be created if needed as such on the local Unix station.

     example:
     O:wheel
     O:bin
     O:staff
     #please don't use O:wheel,bin,staff
     User's will be added to 'standard' Unix group wheel and bin, and to the staff group (probably autocreated).
     

     This feature allows you to register users to specific Unix groups without having to create equivalent groups in NDS.
     In any case, CFLAGS is exactly the same as with users. In 'r' (NDS required) mode, the Unix GID must be read from NDS UNIX:GID (or equivalent property), whereas in 'p' (NDS preferred) mode, an unique GID will be invented (if not found in NDS) from MIN and MAX values and the 'f' (first unused) or 'n' (next unused) flag.

     As above, gid minimal and maximal values if not specified in MIN,MAX will default to respectively 1000 and 60000.

     In contrast to user creation, automatic group creation is not lethal; that is if group creation fails for any reason, user login will not be prohibited.

     Currently there are flags to modify groups, once created.

History:

TODO:

• the module would benefit to read its command line arguments from some /etc/ncpfs.conf file in a section [pam], especially if the current distribution does not have a commun '/etc/pam.d/system-auth' file. Code is almost there ( in the beta ncp_nss library).
• automatic creation of NDS groups to which user belongs should be more configurable. Currently our solution to avoid creating a group is to give it in NDS an alias (N:name) or a GID (G:nnn) equals to an existing one (eg N:users or G:100).
• This module seems to coexist happily here with the current beta version of nss_ncp switch library. Internal calls to getpwdent() ... do fetch NDS datas, so we are doing the same thing twice... in pam_ncp and in nss_ncp. If this library ever gets finalized, one should consider removing automagic creation, but, currently, if no automatic user creation/modification is requested in the command line (no -a and no -u,,r or -u,,p switches), NDS is not read at all, so no more zenflags ... ; some modifications of the pam_sm_authenticate call back function will be needed.
• When ncpmount will accept the -B --broadcast option (as ncplogin/ncpmap do), add a define SET_BCAST atop the source file, or in the Makefile to allow pam_ncp module to honor zenflags (B and C).
• BUG: Force automodification of account if autocreation is requested ( that is -a without any -u flag!)

Vous êtes notre eme visiteur