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