Lecture –Single Login
NIS and Winbind
NIS Network Information Service (NIS) is the traditional directory
service on UNIX platforms Still widely used due to simplicity of setup and maintenance Stores files like /etc/passwd and /etc/hosts in Berkely DB files This information is then made available over the network to all
clients connected to the NIS domain The network connection is not encrypted, all information,
including passwords is sent over the network in clear text NIS (NIS+) version 3 is much more complicated to manage than
NIS version 1 or 2.
NIS Service Description
System-V Managed Service Daemons: ypserv, ypbind, yp-tools Scripts: ypserv, ypbind, yppasswd Ports: Assigned by portmap (111) Config.:
Server: /etc/ypserv.conf, /var/yp/* Common: /etc/sysconfig/network Client: /etc/nsswitch.conf, /etc/yp.conf
NIS Topology
Flat Namespace, no sub-domains allowed One master server per domain Multiple slave servers
Fault tolerance Load sharing
Database on master server based on /etc config files
Configuring a NIS Server Install the ypserv (rpm) package Start ypserv (NIS server daemon) and yppasswd
(NIS password daemon) in the required run-levels In /etc/sysconfig/network file insert the line
NISDOMAIN=<domain name> yppasswd allows NIS server to change the NIS and
passwd database information at the client’s request From the client, you must use yppasswd to change
the password in the NIS Domain
NIS & DNS
The NIS domain name and the DNS domain name are not the same thing
Setting them to the same values is not a good idea
DNS is hierarchical, NIS is not There is no limitation on clients wishing to
join a NIS domain, any system that can reach a NIS domain’s NIS server, can join the domain
Configuring the NIS Master Server
/var/yp/securenets, specify the networks that you wish NIS to serve
Netmask A network
255.255.255.0 192.9.1.0 host 192.0.1.20255.255.255.0 192.9.1.0255.255.0.0 9.9.0.0ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
fec0::111:abba:ace0:fba5e:0host fec0::111:abba:ace0:fba5e:1
Configuring the NIS Master Server
To share only login, group and host information edit /var/yp/Makefile to include ‘all: passwd group hosts netid’
Run /var/lib/yp/ypinit –m Some variables to set
NOPUSH=true/false (for slave servers) MERGE_PASSWD=true/false (for shadow password file) MERGE_GROUP=true/false (for shadow group file)
Configuring the NIS Slave Server
List all slave servers in /var/yp/ypservers Install ypserv (rpm) on slave
Run: /usr/lib/yp/ypinit –s <master>
NIS Client Configuration
On each client machine run NIS client daemon (ypbind) It finds a NIS server by broadcasting a request Or, it can read /etc/yp.conf for a list of YP servers
to use Linux has authconfig utility to set this up
Not a good idea to use broadcast, as a rogue NIS server could be set up on the network
NIS Troubleshooting Use rpcinfo utility to check if the shows available
RPC services on a system service portmap status will tell whether the portmapper
service is running
Use getent on the client to establish if the data is being correctly exported to the clients getent is a generic Linux comment which displays/queries
the databases containing passwd, group, hosts, services ‘getent passwd’ returns the contents of /etc/passwd
If NIS is working, the data should match that on the NIS server.
Winbind
Integration of UNIX and Windows-XP is one of the most important areas in heterogeneous computing
Need to share files between Windows and UNIX systems
Need to be able to assign domain user and group ownerships with integrity
Winbind
Need to allow a single user account to permit logons to both Windows and UNIX systems
winbind is a component of the samba suite that solves the unified logon problem
Uses a UNIX implementation of Microsoft’s RPC calls
(MSRPC) Pluggable Authentication Modules
(PAMs) Name Service Switch
(NSS)
Winbind
Allows Windows domain users to appear and operate as UNIX users on UNIX machines
Provides three separate functions Authentication of user credentials (used by PAM) Identity resolution (used by NSS) Maintains a mapping between UNIX UIDs & GID
and Windows SIDs
Winbind and ID Mapping
For users and groups that do not have a local UID/GID winbind maintains a mapping between existing Windows RIDs and UNIX UID/GID which can be allocated dynamically on demand
Integrating Windows and UNIX
Windows and UINX possess different mechanisms for representing user and group information
Both use different technologies and different record structures for maintaining such information
This fact makes it difficult to integrate Windows and UNIX cleanly
Integrating Windows and UNIX
One solution to integration is to use identically named accounts on both systems
Not an ideal solution as adding and deleting users becomes more complex as we have more systems integrated
The maintenance of two sets of passwords also generates problems
Integration Problems
We could sub-divide the Windows UNIX integration problem into three smaller problems Obtaining Windows user and group information Authenticating Windows users Changing passwords for Windows users
Fortunately, winbind provides a solution to all three problems stated above
Winbind
Winbind allows a UNIX box to become a full member of a Windows domain
Once this is done, the UNIX box will see NT users and groups as if they were native UNIX users
This allows the Windows domain to be used in much the same way in which NIS+ is used in UNIX only environments
Winbind
Whenever any program on the UNIX machine asks the operating system to lookup a user or groupname, the query will be resolved by asking the Windows Domain controller
Because winbind hooks into the operating system at a low level (using the NSS name resolution modules) the redirection to the Domain controller is completely transparent
Winbind
Users on the UNIX machine can use Windows user and group names as they would native UNIX names They are dynamically allocated UNIX uids/gids
from a specified range They can chown files so they are owned by
Windows users They can log into the UNIX machine or run a
UNIX X-Window session as a Windows domain user
Winbind
The only obvious sign that winbind is being used is that the user and group names contain a separator and include the domain name
COMP+rbradley or STUDENT\srooney6 or COMP\STAFF or STUDENT:FT211-4
This domain name inclusion is necessary to allow winbind to know where find the Primary Domain Controller (PDC) to use for resolving the username or groupname
Winbind
Winbind provides an authentication service that hooks into the PAM system Pam_unix connects to the generic “name service
switch” (NSS) which can be configured to call PAM Same mechanism is also used for identity resolution
This addresses the password synchronisation issue, since the password is only stored in one location, the Windows domain controller
Recall: Name Service Switch
Using standard UNIX library calls one can enumerate the users and groups on a UNIX machine running winbind and see all users and groups in a Windows domain plus any trusted domains as if they were local users and groups
For authentication, the passwd config line in nsswitch.conf is:
passwd: files winbind
For name resolution, the hosts config line in nsswitch.conf is:
hosts: files dns winbind
Winbind
Winbind is designed around the client/server architecture
A long running winbindd daemon listens on a UNIX socket for requests to arrive
These requests are generated by the NSS and the PAM clients