Background
File sharing is a basic capability of all enterprise networks. As a matter of fact, time-sharing and file/print sharing accelerated the need for local area networks. In heterogeneous environments it's very common to see Windows Sharing (Server Message Blocks or SMB, better known as Common Internet File System (CFS)) using Windows Servers or UNIX/Linux via Samba's implementation. Traditionally in UNIX and Linux the Network File System (NFS) protocol is widely utilized.
Note that the network file sharing protocol is different than the File System.
For example, in Windows an NTFS (or FAT32) file system can be made available over the network using the CIFS protocol. or in UNIX, an ext3 file system can be made available over the network using the Samba or NFS protocols.
File Sharing meet Identity / Identity meet File Sharing
In order to assign or determine ownership of files and folders, file sharing protocols may rely on OS system frameworks or on proprietary methods to achieve this goal. It's very important to understand the separation of functions, from the moment that the identity of the user (and or groups) is determined, the protocols, methods, and any other functions for file/folder access, manipulation, etc. is implemented between the client and the server based on the network file system specifications.Identification with Samba
Samba provides more than a network file sharing server for SMB/CIFS, it provides the full capabilities to participate in a Windows domain, and even to process authentication requests, including directory, authentication, file/print services, etc. (and with Samba 4 the capabilities are closer to an Active Directory infrastructure). Samba servers can be implemented in standalone mode, as a member of a classic NT domain or an Active Directory Domain services file and print server.
Regardless of the mode, Samba uses the the IDMapper facility implemented generally with the Winbind daemon (winbindd) to perform the identification process. Notice that the IDMapper is NSS-aware (this is great for us, because Centrify is NSS-aware too):
In the case of Winbind, there are several options available, but regardless, the options are to generate a UID/GID based on a predefined range of numbers or with some algorithm. These UID/GID entries are being tracked locally in the Samba server. This represents a challenge of a different nature, but it's possible for Samba to leverage LDAP too.passwd: files winbindThings get complex because both Samba and us have (or can generate in the case of Winbind) information about UID/GIDs!!
In a test Ubuntu box (UBU1) we have configured Samba and Winbind and joined our AD domain an here's an exerpt of the /etc/samba/smb.conf file:
[Global]
workgroup = CORP
realm = corp.contoso.com
server string = Samba Server
security = ads
template shell = /bin/bash
idmap uid = 500-1000000
idmap gid = 500-1000000
winbind use default domain = Yes
The effect that this has, is that Winbind will start from 500 all the way to the boundary to provide UID/GIDs to the Active Directory users. This can be verified with the getent command (excerpt):
administrator:*:500:500:Administrator:/home/CORP/administrator:/bin/bash
guest:*:501:501:Guest:/home/CORP/guest:/bin/bash
krbtgt:*:502:500:krbtgt:/home/CORP/krbtgt:/bin/bash
bryant.wheeler:*:504:500:Bryant Wheeler:/home/CORP/bryant.wheeler:/bin/bash
jessie.matthews:*:505:500:Jessie Matthews:/home/CORP/jessie.matthews:/bin/bashcora.rodriguez:*:506:500:Cora Rodriguez:/home/CORP/cora.rodriguez:/bin/bash
courtney.larson:*:507:500:Courtney Larson:/home/CORP/courtney.larson:/bin/bash
jeremy.silva:*:508:500:Jeremy Silva:/home/CORP/jeremy.silva:/bin/bash
ramon.jimenez:*:509:500:Ramon Jimenez:/home/CORP/ramon.jimenez:/bin/bash
doyle.russell:*:510:500:Doyle Russell:/home/CORP/doyle.russell:/bin/bash
matt.sims:*:511:500:Matt Sims:/home/CORP/matt.sims:/bin/bash
cassandra.lindsey:*:512:500:Cassandra Lindsey:/home/CORP/cassandra.lindsey:/bin/bash
ralph.baldwin:*:513:500:Ralph Baldwin:/home/CORP/ralph.baldwin:/bin/bash
sqlagent:*:514:500:SQL Server Agent:/home/CORP/sqlagent:/bin/bash
sqldatabase:*:515:500:SQL Server Database:/home/CORP/sqldatabase:/bin/bash
centrify.zpa:*:516:500:Zone Provisining Agent:/home/CORP/centrify.zpa:/bin/bash
Notice important differences:
- All the users in the domain are valid users of the Samba server (this can be limited)
- And like we described above, starting with administrator, the UID/GIDs are assigned sequentially.
- No identity overrides (this can cause an issue in legacy UNIX)
Note the output for CEN1
$ adquery user
jmatthews:x:1149240406:1149240406:Jessie Matthews:/home/jmatthews:/bin/bash
jsilva:x:1149240409:1149240409:Jeremy Silva:/home/jsilva:/bin/bash
rjimenez:x:1149240410:1149240410:Ramon Jimenez:/home/rjimenez:/bin/bash
The Centrify client only allows access based on the governance set up (least access). Also notice the differences. If Jessie connects to a Samba share in this server (via Windows or UNIX) and creates a file (smbtest.txt), the IDMap facility will use the 505 UID, and the way the Samba server is set up, it will assign a GID of 500 (Domain Users).
$ls -la
total 8
drwxrwxrwx 2 nobody nogroup 4096 Jan 11 19:43 .
drwxr-xr-x 3 root root 4096 Jan 11 17:14 ..
-rwxr--r-- 1 jessie.matthews domain users 0 Jan 11 19:43 smbtest.txt
ls -lan
total 8
drwxrwxrwx 2 65534 65534 4096 Jan 11 19:43 .
drwxr-xr-x 3 0 0 4096 Jan 11 17:14 ..
-rwxr--r-- 1 505 500 0 Jan 11 19:43 smbtest.txt
At least with NFS, the anonymous request would send the UID/GID over RPC, however by no means this is an advantage of NFS over Samba (quite the contrary), but it requires additional components in addition to adclient to work correctly. So now you have the same issue as depicted in the previous posting in which users are calling to get ownership of their files and in some cases this can cause outages of services that leverage remotely-mounted filesystems for configuration files.
Centrify-enhanced Samba
Centrify-enhanced Samba implements the same Samba version but with an IDMapper facility that is Zone-aware, it makes the algorithm very simple: If the user has an identity in the zone (UID/GID) that is the one that will be assigned. Instead of joining the domain with the samba-winbind-heimdall Kerberos combo, the system is joined to the domain with adclient and Centrify-enhanced Samba is installed. A process called adbindproxy uses zone information to perform the correct mapping. Centrify includes utilities to migrate existing UID/GID info from Winbind to the Centrify zone.
Identity-overrides caveat: The assumption here is a normalized namespace (hence my insistence that it is the ideal UNIX namespace state); Identity overrides (at the zone, child zone or system levels) are exceptions and any exceptions carry inconsistencies.
This is why performs a Samba check when the adcheck utility is run
$ adcheck corp.contoso.com
OSCHK : Verify that this is a supported OS : Pass
<...>
SAMBA : Inspecting Samba installation : Note
The installed version of Samba was not supplied by Centrify.
You may wish to install Centrify's Samba which is optimized for
interoperability with both DirectControl and Active Directory.
<...>
What are the options?
- As stated above, quickest solution is to Centrify the system and leverage Centrify-enhanced Samba.
- If the Samba server is an appliance, there are utilities (like the Centrify LDAP and NIS proxies) to provide the appliance with the identity information required to perform the adequate UID/GID assignment. This post covers the implementation of the LDAP proxy on a NetApp appliance.
No comments:
Post a Comment