Lecture – Single Login

1. Lecture –Single Login NIS and Winbind

2. 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.

3. 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

4. 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

5. 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

6. 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

7. 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.20 255.255.255.0 192.9.1.0 255.255.0.0 9.9.0.0 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fec0::111:abba:ace0:fba5e:0 host fec0::111:abba:ace0:fba5e:1

8. 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)

9. 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>

10. 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

11. 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.

12. 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

13. 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)

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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 passwdconfig line in nsswitch.confis:passwd: files winbind For name resolution, the hosts config line in nsswitch.confis: hosts: files dnswinbind

25. 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