Transcript Unix/Windows Operability

Unix/Windows Inter-Operability
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?
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
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
Shadow File
• Remove DES # from public passwd file
• Shadow file only access by local root
• Add account management for password
change frequency, expiry, etc
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.
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
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
[email protected]
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
nsswitch.conf
• Controls where each nameservice gets its
information
passwd:
group:
hosts:
netgroup:
files ldap
compat
nis dns [NOTFOUND=return] files
nis
• Compat allows +/-[@netgroup] syntax in files
• getent instead of ypmatch an ldapsearch
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
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
Pluggable Authentication Modules
• Stack of modules in 4 contexts
– Auth:
– Account:
– Session:
– Password:
User authentication
password/account expiry etc
session management e.g. logging
how to change password etc.
• Each service such as login, ftp etc can have its
own stacks
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
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-cache
hosts
no
Authentication vs Authorization
AUTHENTICATION
AUTHORIZATION
KERBEROS
TICKET
Windows Privilege Access
Certificate (PCA) in TGT contains
user and group SID
LDAP
Implementation
Dependant
Schema objects and attributes
Authentication
Name Server
UNIX NS
AD LDAP
AD Kerb.
1.
2. Modify AD, pam.conf and
nsswitch.conf
AD LDAP
3.Modify pam.conf
4.
UNIX Kerb
5. Kerberos Cross Realm
Trust
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
Option Requirements
Option
AD Kerberos
AD LDAP
UNIX Kerberos
UNIX NS
1
Yes
Yes
No
No
2
Yes
No
No
Yes
3
No
Yes
No
Yes
4
No
Yes
No
No
5
Yes
No
Yes
Yes
1. AD Kerberos Auth, UNIX NS
• Pros
– Same username/password
– Existing name service
– Single Sign On available
• Cons
– Need to maintain UNIX NS
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
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
3. AD LDAP Auth, UNIX NS
• Pros
– Same username/password
– Existing name service
• Cons
– Need to maintain UNIX NS
– No Single Sign On
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
5. Cross Realm Trust
• Pros
– Native Tools
– User Prinicpals in AD, Unix Services and Hosts
Prinicpals in Unix Kerberos
• Cons
– Extra complication
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
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
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
Network File System
• Mount directory from server on client (c.f.
map network share)
• Host based security
• Client does authorization by user/group
NFS V4
• Server side authorization
• NTFS like Access Control Lists
• Kerberos Support
– Authentication
– Integrity
– Encryption
• Client Prinicpal need to allow root to mount
filesystem
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.
LUFS/FUSE
•
•
•
•
•
Allows normal user to mount “filesystem”
Present sftp connection as filesystem
Other backends available
Similar problems to smbmount
Performance issues?