1. Unix/Windows Inter-Operability

2. What do we want? Single Username Password Access Users files (N drive) – Personal Machine – Multi-User Machines Information about users – Name Service Simple Client Setup Multiple Namespaces?

3. UNIX files /etc/passwd – User account information – Name:DES#:uid:gid:Display Name:homedir:shell /etc/group – Group information and membership – Name:[hash]:gid:user1,user2... /etc/hosts.... Files are readable by all users

4. DES Encryption Encrypt 64bit 0 25 times using 12bit salt and 8 7bit character password (56bit). Designed to take 1 second on 1979 hardware. Brute force ~ 23,000,000,000 years. Only 94 characters on keyboard ~54.2bits Moore’s law – 500,000 per sec ~4500 years. – Dictionary attack takes only minutes

5. Shadow File Remove DES # from public passwd file Shadow file only access by local root Add account management for password change frequency, expiry, etc

6. Yellow Pages (aka NIS) Service on the network based on maps containing key-value pairs Add + at the end of files in /etc All machines in the same namespace see the same information. Central management of user accounts etc. Information now visible to all users on any machine on the network.

7. LDAP Lightweight Directory Access Protocol General mechanism Schema used to define objects Objects have named attributes Objects can be extranded Can require authentication to connect Can secure individual objects

8. LDAP vs NIS  ypmatch –d rucsc 11420 passwd.byuid sssadw:x:11420:11203:Anthony Worrall:/home/sufs1/ru10/ss/sssadw:/bin/csh  ldapsearch -h host -b "ou=people,dc=sse,dc=rdg,dc=ac,dc=uk" uidNumber=11420 uid=sssadw,ou=People,dc=sse,dc=rdg,dc=ac,dc=uk cn=Anthony Worrall mail=Anthony.Worrall@Reading.ac.uk uid=sssadw givenName=Anthony sn=Worrall objectClass=person objectClass=organizationalPerson objectClass=inetOrgPerson objectClass=dspswuser objectClass=account objectClass=posixAccount objectClass=shadowAccount objectClass=top loginShell=/bin/csh uidNumber=11420 gidNumber=11203 homeDirectory=/home/sir/sssadw gecos=Anthony Worrall

9. nsswitch.conf Controls where each nameservice gets its information passwd:files ldap group:compat hosts: nis dns [NOTFOUND=return] files netgroup:nis Compat allows +/-[@netgroup] syntax in files getent instead of ypmatch an ldapsearch

10. Kerberos An Authentication Service (KDC) Obtian a ticket (Passport) at login Use ticket to access other services. Can also be used to authenticate clients, services, and encrypt traffic Based on principals “username@realm” Realms can have a trust relationship Pre-authentication need for security

11. Kerberos client tools kint – Get ticket for a prinicpal using information from user input or file klist – List principals for current user or stored in a file kdestroy ktutil – Mange princiapls in a keytable files

12. Pluggable Authentication Modules Stack of modules in 4 contexts – Auth:User authentication – Account:password/account expiry etc – Session:session management e.g. logging – Password:how to change password etc. Each service such as login, ftp etc can have its own stacks

13. Configuring Linux in SSE LDAP Settings LDAP Server : sse.ad.rdg.ac.uk Search Base : ou=unix,dc=sse,dc=ad,dc=rdg,dc=ac,dc=uk Group member attribute : member Kerberos Settings Default Domain : rdg.ac.uk Default Realm : RDG-HOME.AD.RDG.AC.UK KDC : rdg-home.ad.rdg.ac.uk

14. Name Service Cache Deamon NSCD save results of NameService requests including DNS lookups Some services on multiple machines – rdg-home.ad.rdg.ac.uk – timehost.rdg.ac.uk Modify /etc/nscd.conf – enable-cachehostsno

15. Authentication vs Authorization AUTHENTICATIONAUTHORIZATION KERBEROSTICKETWindows Privilege Access Certificate (PCA) in TGT contains user and group SID LDAPImplementation Dependant Schema objects and attributes

16. Name Server UNIX NSAD LDAP Authentication AD Kerb.1.2. Modify AD, pam.conf and nsswitch.conf AD LDAP3.Modify pam.conf4. UNIX Kerb5. Kerberos Cross Realm Trust

17. Options of Integration 1.AD Kerberos Authentication, UNIX name service 2.AD Kerberos Authentication, AD name service 3.AD LDAP Authentication, UNIX name service 4.AD LDAP Authentication, AD name service 5.UNIX Kerberos with cross realm trust for authentication and UNIX name service

18. Option Requirements OptionAD KerberosAD LDAPUNIX KerberosUNIX NS 1Yes No 2YesNo Yes 3NoYesNoYes 4NoYesNo 5YesNoYes

19. 1. AD Kerberos Auth, UNIX NS Pros – Same username/password – Existing name service – Single Sign On available Cons – Need to maintain UNIX NS

20. 2a. AD Kerberos, AD NS Pros – Single username/password – Single Name Store – 2003R2 supports RFC 2307 (homeDirectory?) Cons – Need to extend “user” class – Map Classes and Attributes on clients

21. 2b. AD Kerberos, AD NS separate OU Pros – Only need AD DC’s – Looks like UNIX OpenLDAP to clients (RFC 2307) – Allows Multiple Name Spaces Cons – Need to promote PosixAccount Class – Synchronise information between OU

22. 3. AD LDAP Auth, UNIX NS Pros – Same username/password – Existing name service Cons – Need to maintain UNIX NS – No Single Sign On

23. 4. AD LDAP Auth, AD NS Pros – Only need AD DC’s Cons – Need to extend users class or promote PosixAccount class – No Single Sign On – Need Proxy User to access NS

24. 5. Cross Realm Trust Pros – Native Tools – User Prinicpals in AD, Unix Services and Hosts Prinicpals in Unix Kerberos Cons – Extra complication

25. Authentication Kerberos Pros – Single Sign On to services – Apache Module – Authenticate services Cons – Host and Service Prinicples Modify – krb.conf – pam.conf – krb5.keytab AD LDAP Pros – Simple – Used by web backends (PHP, Perl), Apache Module Cons – need to secure connection Modify – pam.conf

26. AD as NS Extend user class Pros – Single object to maintain Cons – Map objects and attributes on client (e.g. uid => sAMaccountName ) Promote PosixAccount Pros – Looks like UNIX OpenLDAP to clients – Allows Multiple Name Spaces Cons – Synchronise information between OU

27. Unix Name Service LDAP Pros – Out of the BOX – Can be restricted Cons – Complicated – Proxy User on clients if restricted NIS Pros – Simple – Configuration by DHCP Cons – World readable

28. Network File System Mount directory from server on client (c.f. map network share) Host based security Client does authorization by user/group

29. NFS V4 Server side authorization NTFS like Access Control Lists Kerberos Support – Authentication – Integrity – Encryption Client Prinicpal need to allow root to mount filesystem

30. smbmount Mount folder from Windows server using cifs protocol Single username and group mapping Need root access (sudo) to do mount Requires username and password on command line, in a file or user input.

31. LUFS/FUSE Allows normal user to mount “filesystem” Present sftp connection as filesystem Other backends available Similar problems to smbmount Performance issues?