Integração Unix / MS-Windows

Introdução

A integração de sistemas consiste em criar as condições necessárias para que os sistemas possam trocar informação entre sí, a vários níveis, normalmente usando comunicações em rede. A necessidade de integração de sistemas derivou directamente da generalização da utilização das redes de computadores.

Seja qual for o nível de integração, para ela ser possível é sempre necessário usar algo que seja comum aos sistemas em causa. O elo comum pode ser por exemplo um protocolo de rede, ou a um nível mais elevado, uma aplicação.

A integração de sistemas heterogéneos foi durante muito tempo um desafio dificil de superar e recheado de componentes de "software" "especiais" conhecidos por "gateways" de aplicação. Nesses tempos não muito longinquos não existia um protocolo de rede "universal" como acontece actualmente com o IP ("Internet Protocol"), cada sistema usava os seus conjuntos de protocolos de rede ("pilha de protocolos") especificos:

• IBM: SNA
• Microsoft: NetBEUI/NetBIOS
• Apple: AppleTalk
• Digital: DNA / PathWorks
• Novell: IPX/SPX
• Xerox: XNS
• Unix: TCP/IP

Para agravar mais as coisas, a maioria destes sistemas eram do tipo "proprietário", ou seja sob o ponto de vista legal apenas podiam ser usados pelas entidades que detinham os respectivos direitos. Além disso essas entidades raramente revelavem detalhes sob o funcionamento interno dos seus protocolos.

Quando sistemas de diferentes tipos eram confrontados numa rede, não existia qualquer possibilidade de trocarem informação entre sí usando os respectivos protocolos. O elo comum, que permite a integração, apenas surge no nível de aplicação, com conceitos tais como:

• EMULAÇÃO DE TERMINAL EM REDE
• TRANSFERÊNCIA DE FICHEIROS E DIRECTÓRIOS
• TRANSFERÊNCIA DE MENSAGENS

O facto de existirem aplicações semelhantes nos vários tipos de sistemas é apenas o ponto de partida. Estas aplicações semelhantes estão completamente isoladas umas das outras por conjuntos de protocolos subjacentes totalmente diferentes uns dos outros.

Nestes tempos, a única forma de se conseguir a integração consistia na utilização de um sistema especial que suportasse mais do que uma pilha de protocolos. Nesse sistema poderia então ser instalada uma aplicação especial capaz de usar ambas as pilhas, a missão dessa aplicação é, usando os protocolos de aplicação especificos de cada pilha (Ex.: transferência de ficheiros) assegurar, para esse tipo particular de aplicação, uma porta de ligação entre os dois "mundos". Este tipo de sistema é conhecido por "gateway" de aplicação.

Exemplo: Novell / SMTP As redes Novell possuem um sistema de correio electrónico, baseado nos respectivos servidores que foi bastante popular. Este sistema usa directórios especiais partilhados pelo servidor, usando a pilha de protocolos IPX/SPX. Quando começõu a expansão da "internet", todos se puderam aperceber da grande desvantagem de usarem um sistema "proprietário" que como tal estava fechado em si mesmo, não permitindo por isso o envio e recepção de mensagens de correio para além dos servidores Novell. A troca de mensagens de correio na "internet" usa o protocolo SMTP ("Simple Mail Transfer Protocol"). A solução foi a instalação de um "gateway" de aplicação para correio electrónico. Esta aplicação estava instalada num sistema MS-DOS com duas pilhas de protocolos: IPX/SPX + Cliente Novell TCP/IP + Servidor SMTP A aplicação em causa é constituida por um servidor SMTP e por um "cliente Novell", funcionado do seguinte modo: - Quando o servidor SMTP recebe uma mensagem da "internet", usa o "cliente Novell" para depositar a mesma na "mailbox" adequada no servidor Novell. - Usa o "cliente Novell" para verificar se existem no servidor Novell mensagens para serem enviadas para o exterior, nesse caso retira-as e usa o protocolo SMTP para as enviar para a "internet" Deste modo os utilizadores habituais do correio electrónico da Novell puderam continuar a usar o mesmo sistema e o mesmo "software" e passaram a ter disponível não só o correio electrónico local (Novell) como também o da "Internet" (SMTP).

Nos anos seguintes, por pressão dos utilizadores, todos os sistemas operativos passaram gradualmente a suportar o protocolo IP, indispensável para a utilização da "internet". Este facto veio alterar totalmente a interligação de sistemas heterogéneos, pela simples razão de que esses sistemas passaram a ter um elo comum ao nível dos protocolos de rede, basta agora ter aplicações compativeis entre os vários sistemas e a integração está desde logo assegurada.

Por exemplo, na actualidade, para transferir ficheiros entre sistemas diferentes, sejam eles por exemplo, MacOS, MS-Windows, OS/400 ou Unix, poderá sempre ser usado o protocolo de aplicação FTP que usa o conjunto TCP+IP comum a todos esses sistemas.

Integração de sistema na actualidade

Com a pilha de protocolos TCP/IP disponível em todos os sistemas operativos os problemas de integração são agora totalmente diferentes, os problemas são agora muito pontuais, afectando apenas aplicações muito específicas, normalmente muito relacionadas com a estrutura do sistema operativo em sí.

As áreas de mais dificil integração, onde subsistem dificuldades são:

Bases de dados de utilizadores	Os sistemas associam a cada utilizador um identificador, são notorias as diferenças de formatos, por exemplo em Windows são usados os SID, bastante extensos e em Unix os UID com 16 bits. O registo associado a cada utilizador (conta de utilizador) contém campos que diferem substancialmente entre os vários sistemas. Isto dificulta a utilização de contas de utilizador que residem num sistema de tipo diferente. Por exemplo em Unix (/etc/passwd), estes campos são extremamente limitados. A forma de armazenamento e validação das "passwords" é substancialmente diferente entre os diversos sistemas.
Sistemas de ficheiros de rede	Os protocolos de acesso a servidores de ficheiros ("File Servers") estão ainda muito dependentes dos sistemas operativos, deixando transparecer as caracteristicas dos sistemas de ficheiros locais e utilizando filosofias diferentes. Por exemplo em Unix o acesso aos servidores de ficheiros (NFS) é configurado pelo administrador e disponibilizado aos utilizadores. Em MS-Windows, os utilizadores acedem directamente aos servidores de ficheiros (SMB), autenticando-se. Mantendo o mesmo exemplo (Unix vs. MS-Windows), as ACL's são totalmente diferentes, e essas ACL's transparecem directamente para o acesso remoto aos servidores.
Acesso remoto em modo gráfico	Os sistemas Unix utilizam o ambiente gráfico X-Windows que é por concepção distribuído, assim sendo o acesso em modo gráfico a sistemas Unix é bastante simples, bastando usar o "software" apropriado. Para mais informação, consultar "Ambiente X-Windows distribuído". O acesso em modo gráfico a sistemas não Unix é bastante mais complicado, nos anos recentes têm sido desenvolvidos alguns sistemas do tipo "Thin Client" e a MicroSoft desenvolveu o RDP ("Remote Desktop Protocol") que tem o inconveniente de apenas poder ser usado entre sistemas MS-Windows. O acesso remoto em ambiente gráfico com recurso a protocolos especiais está a perder importância devido à crescente disponibilização de aplicações baseadas em servidores WEB. Estas aplicações, dos mais diversos tipos, são acessiveis remotamente através de um simples "browser", disponível em qualquer plataforma.

O "software" Samba

O Samba (http://www.samba.org) é um conjunto vasto de programas "open-source", especialmente desenvolvidos para Linux (embora seja suportado por muitas implementações Unix e não só) cujo grande objectivo é a integração do sistema Unix no ambiente de rede da Microsoft.

Embora os mais notórios sejam os componentes que implementam as funções de servidor, sendo considerado "o servidor Windows mais rápido existente", o "software" Samba no seu conjunto permite um elevado grau de integração dos sistemas Unix no ambiente de rede Microsoft, em diversos aspectos e sob diversos tipos de configuração.

Sob uma perspectiva de substituição dos sistemas servidores da Microsoft é fundamental compreender que o Samba não é suportado de forma alguma pela Microsoft (antes pelo contrário). Uma vez que os sistemas Windows são proprietários, para cada evolução nos sistemas Microsoft, existe um lapso de tempo razoável até que as mesmas funcionalidades sejam suportadas pelo Samba. Esse lapso de tempo corresponde a um processo de investigação das novas funcionalidades e implementação das mesmas.

Por exemplo, de momento (Novembro de 2003), o Samba tem como última versão estável "3.0.0", algumas das caracteristicas como servidor são:

• Suporte total das funções "Primary Domain Controller" (PDC) tal como eram implementadas pelo "Windows NT Server 4.0". Não suporta ainda as funções PDC em modo "Active Directory" do "Windows 2000 Server".
• Pode contudo integrar-se num dominio "Active Directory".
• Suporta o MS-DFS (sistema de ficheiros distribuído da MicroSoft).
• Suporta o sistemas avançados de impressão, incluido a instalação automática de "drivers".

Muitas vezes a simples instalação de um novo "Service Pack" nos clientes pode provocar problemas, novamente é necessário esperar algum tempo até que a equipa que desenvolve o Samba resolva essa situação.

Servidor Samba

O servidor Windows é constituido por duas aplicações separadas:

• nmbd - esta aplicação implementa as funções NetBIOS de resolução de nomes, registo de nomes e recolha de listas de "browse". Pode funcionar como servidor WINS ou usar servidores WINS existentes.
• smbd - é o servidor propriamente dito, desde logo implementa o protocolo SMB para acesso aos ficheiros, mas vai muito além disso, acompanhando as funcionalidades crescentes dos servidores Microsoft, assim actualmente implementa ainda os protocolos ADS, RAP e RPC.

Sob o ponto de vista das funções de controlador de domínio o servidor é equivalente a um controlador de domínio NT Server, com todas as funcionalidades associadas tais como:

• Autenticação com "password" protegida (cifrada).
• Identificação por SID.
• "Login" no domínio com fornecimento de credenciais que permitem o acesso a todas as máquinas do domínio. As máquinas do dominio podem incluir qualquer tipo de sistema da Microsoft (NT, 2000, XP, ...) nas versões "Server" ou "Workstation".
• "Login Script".
• "Home Directory" e "Roaming Profile".
• "Politicas de Sistema".

ACLs

As ACLs que se espera de um servidor Windows são substancialmente diferentes das ACLs do Unix ("Posix ACLs"), o servidor Samba tenta criar uma equivalência o mais coerente possível, assim:

• O UID e GID dos ficheiros Unix é transformado em SIDs.
• Apenas são possíveis as permissões RWX, na ausencia de permissões, é activada a permissão Windows "O" (por semelhança com o 0).
• As permissões Unix correspondentes ao UID são apresentadas sob a forma de uma entrada na ACL, com o SID equivalente.
• As permissões Unix correspondentes ao GID são também transformadas numa entrada na ACL, agora com o SID corespondente ao GID.
• As permissões Unix correspondentes a "others" são materializadas na ACL sob a forma de uma entrada associada ao grupo "EVERYONE".

Os atributos Windows "Archive", "System" e "Hidden" também não têm qualquer equivalente em Unix, o servidor Samba permite no entanto que estes atributos sejam associados aos bits "execute" do Unix, respectivamente para o "owner", "grupo" e "others".

Bases de dados do Servidor Samba

O servidor Samba tem necessidade de manter um vasto conjunto de informação necessário às funções de servidor Windows, de entre esta informação assume particular destaque as contas dos utilizadores. Entre outras informações as contas de utilizador Windows devem conter:

• O nome do utilizador.
• O SID do utilizador.
• O SID do grupo primário do utilizador.
• A "password" do utilizador (armazenada em dois formatos de cifragem distintos adequados a dois tipos diferentes de postos de trabalho).
• A localização da "home directory".
• A localização do "roaming profile" ("profile path").
• A letra de drive a mapear para a "home directory".
• O "login script" do utilizador.
• O nome completo do utilizador.
• A descrição da conta.
• Os postos de trabalho que o utilizador pode usar.
• Tipo de conta (Utilizador, Máquina, Disabled, ...).
• Politicas de conta (mudança de password, etc).

O conjunto de informação relativo às contas de utilizador em Windows é normalmente conhecido por SAM ("Security Account Manager"). O tipo de base de dados que o Samba usa para guardar este tipo de informação pode ser de diversos tipos (tipo de "backend").

Até à versão 3, o servidor samba usava para este efeito o ficheiro "smbpasswd" que era claramente omisso em muitos aspectos. Para cada utilizador, este ficheiro contém apenas o nome, o UID unix, o tipo de conta e as "passwords" cifradas, os restantes parâmetros tinham de ser iguais para todos os utilizadores, podendo incluir elementos que eram automaticamente substituidos pelo nome do utilizado. O SID era calculado em função do UID com recurso a uma regra aritmética simples (SID-utilizador=SID-domínio-RID, onde RID=1000+2xUID).

Com a versão 3.0.0 passaram a ser suportadas diversas formas de armazenamento para além do "smbpasswd", de entre elas MySQL e LDAP. Estas novas formas de armazenamento não possuem as limitações do "smbpasswd" e suportam todos os campos necessários a uma conta de utilizador de um domínio Windows.

De entre as várias opções disponíveis actualmente, uma das mais atractivas sob o ponto de vista de integração é o LDAP.

Utilizadores Unix e utilizadores Windows

Embora o Samba defina contas de utilizador apropriadas para o ambiente de domínio Microsoft, internamente tem de funcionar com contas Unix, porque apenas estas são reconhecidas pelo Sistema Operativo.

Para cada conta de utilizador Windows, definida no Samba, tem de existir uma conta Unix equivalente, ou seja não se pode criar um utilizador Windows no Samba, sem antes ter criado o utilizador Unix correspondente. Sob o ponto de vista do administrador isto não é muito favorável porque terá de gerir em paralelo duas bases de dados de utilizadores (Unix e Windows/Samba).

As versões actuais do servidor Samba permitem a definição de um programa externo que será executado quando vai ser criado um novo utilizador Windows, a missão desse programa externo é a de criar automaticamente o utilizador Unix correspondente.

Se pretendemos um maior grau de integração Unix/Windows, o LDAP leva vantagem porque devido ao facto de o Unix suportar utilizadores em LDAP (nss_ldap e pam_ldap), e graças ao modo como o LDAP funciona, é possível ter os utilizadores em registos únicos, contendo os campos necessários tanto para o Samba como para o Unix.

Grupos Unix e grupos Windows

O Samba permite estabelecer relações de equivalência entre grupos de utilizadores Windows e grupos de utilizadores Unix. A necessidade de equivalência deve-se ao facto de (tal como para os utilizadores) o servidor Samba funcionar sobre Unix e como tal, no acesso ao sistema operativo, tem de usar UIDs e GIDs Unix.

Esta relação de equivalência é definida pelos administradores, ficando associado ao grupo Windows, com respectivo SID um grupo Unix válido. Este procedimento tem também a vantagem de contornar as limitações dos nomes de grupos Unix, que por exemplo não podem conter espaços, existentes na maioria dos grupos Windows fundamentais como "Domain Admins", "Domain Users" e "Domain Guests".

Suporte de BDC ("Backup Domain Controller")

Os dominios da Microsoft sustentam-se numa máquina com funções especiais conhecido por "Primary Domain Controller" (PDC). Esta máquina tem obrigatoriamente de ser única e mantém uma base de dados contendo todas as definições relativas ao domínio, tais como contas de utilizador, definições de grupos de utilizadores, contas de máquinas que pertencem ao domínio, etc, ou seja a base de dados SAM.

A função PDC é identificada através do nome NetBIOS correspondente ao domínio, com o tipo de nome "1b". Sempre que é necessário alterar algo num domínio (por exemplo a "password" de um utilizador), este servidor tem de estar disponível. Além do tipo de nome "1b", um PDC define também o nome de domínio, do tipo "1c", o tipo "1c" significa "Login Server", ou seja trata-se de um servidor que é possível usar para efectuar o "login" no domínio. Os postos de trabalho procuram o nome de domínio do tipo "1c" para saberem onde é que os utilizadores devem efectuar o "login" no domínio.

As alterações à base de dados SAM apenas podem ser feitas no PDC, contudo nada impede que existam cópias redundantes e apenas de leitura, disponíveis em outros servidores, esses servidores podem então assumir a função "Backup Domain Controller". Um BDC não define o tipo de nome "1b", isso é reservado ao PDC que tem de ser único, mas define o nome de domínio do tipo "1c", ou seja é um "Login Server".

A vantagem de se dispor de um ou mais BDCs é que em caso de indisponibilidade temporária do PDC continua a ser possível efectuar o "login" no domínio, e a base de dados SAM continua disponível (nos BDC). Contudo todas as operações que envolvem alterações à base de dados são impossíveis até que o PDC esteja disponível. A existência de vários "Login Server" tem ainda a vantagem de distribuir essa tarefa por vários servidores.

Actualmente os servidores Samba não suportam ainda os protocolos de sincronização PDC/BDC usados pela Microsoft, isto significa que o Samba pode ser BDC apenas de domínios cujo PDC é também um servidor Samba. Para isso é necessário assegurar a sincronização manual por meios externos, além da base de dados, o administrador não se pode esquecer ainda do "share" NETLOGON que deve ser igual no PDC e nos vários BDC (o NETLOGON contém elementos fundamentais tais como o "login script" e as politicas de sistema).

Uma das formas mais directas de assegurar a sincronização dos BDC com o PDC é usar um sistema de servidores LDAP, por exemplo o OpenLDAP (http://www.openldap.org) dispõe de mecanismos de replicação que permitem manter um conjunto de servidores LDAP sincronizados entre sí.

Servidores Samba integrados em domínios Microsoft

A grande vantagem dos servidores Samba é a sua eficiência e estabilidade, a grande desvantagem reside no facto de nunca implementar as últimas funcionalidades desenvolvidas pela Microsoft. Por estas razões pode ser boa ideia usar um servidor Windows da Microsoft para controlador de domínio e integrar no domínio servidores Samba a proporcionar outras funcionaliadades, tais como servidor de ficheiros.

O servidor Samba suporta perfeitamente a integração em dominios, incluindo domínios "Active Directory". Quando o servidor Samba faz parte de um domínio, as contas de utilizador residem no PDC, ao qual se recorre sistematicamente para obter os SID dos vários recursos em jogo.

Quando o sistema Unix é membro de um domínio controlado por um servidor MS-Windows, as contas de utilizador residem no sistema MS-Windows, o problema de integração mantém-se, é necessário que para cada utilizador Windows exista um equivalente Unix. Novamente o Samba oferece a possibilidade de um elevado nível de integração: o "winbind".

O winbind é composto por:

• Servidor ("winbindd") que se encarrega do contacto com o servidor Windows por forma a obter informações sobre utilizadores e grupos aí existentes. Entre outras missões, este servidor mantém uma tabela de equivalências entre utilizadores do sistema MS-Windows e utilizadores Unix, gerando os UIDs apropriados para cada SID correspondente a um utilizador Windows e mantendo as associações UID/SID entre sessões.
• Modulo nss_winbind (/lib/libnss_winbind). Esta biblioteca NSS ("Name Service Switch") usa o servidor "winbind" e permite que os utilizadores do sistema Windows sejam válidos no sistema Unix. Para cada nome de utilizador obtém o respectivo UID/GID, "login shell", "home directory", ...
• Modulo pam_winbind (/lib/security/pam_winbind). Esta biblioteca PAM ("Pluggable Authentication Modules") permite que os utilizadores do sistema Windows se autentiquem (Username/Password) perante o sistema Unix. Tal como o anterior usa o servidor "winbind" como intermediário.

O servidor "winbind" é um "gateway" de aplicação, recebe pedidos do "nss_winbind" e do "pam_winbind" e usa a base de dados de utilizadores residente no sistema servidor MS-Windows para proporcionar a informação que estes modulos necessitam.

Quando o servidor "winbind" tem de resolver um nome, contacta o servidor Windows e este fornece-lhe o respectivo SID. Para obter o UID Unix equivalente o "winbind" verifica se o SID existe na sua base de dados, em caso afirmativo devolve o UID que lhe está associado.

Se o SID não está na base de dados, acrescenta-o, associando-lhe um novo UID que esteja livre no sistema Unix (o "winbind" permite que o administrador defina uma gama de UIDs para este efeito). Nesta altura o "winbind" pode, por opção do administrador, criar uma conta Unix local, nesse caso, para esse utilizador, o "pam_winbind" deixará de ser necessário, uma vez que o utilizador passa a ser local.

Seja ou não criada uma conta local para o utilizador, existe um conjunto de parâmetros Unix que o servidor "winbind" tem de fornecer conjuntamente com o UID recém definido ("primary group", "home directory", "login shell"). Estes parâmetros não existem na conta de utilizador Windows, por isso o "winbind" utiliza "templates", basicamente trata-se de valores que serão iguais para todos os utilizadores, mas que eventualmente podem ter uma parte substituida por elementos variáveis, por exemplo para a "home directory" poderá ser usado algo como:

O elemento "%U" será depois substituido pelo nome do utilizador, caso a caso.

O "winbind" suporta não apenas nomes de utilizadores, mas também nomes de grupos, o principio de funcionamento é semelhante havendo tal como acontece para os utilizadores a possibilidade de criar grupos locais para corresponderem aos do sistema MS-Windows ou manter a utilização do "nss_winbind". Além de utilizadores e grupos, o "winbind" também resolve nomes de máquinas, utilizando o mecanismo NetBIOS, quer recorrendo a "queries broadcast", quer recorrendo a servidores WINS.

A grande vantagem do "winbind" é que o administrador apenas necessita de gerir utilizadores no sistema servidor Windows. Quando um novo utilizador Windows é criado, fica a ter automaticamente acesso ao sistema Unix, durante o primeiro acesso o "winbind" reserva um UID para esse novo utilizador e eventualmente cria mesmo uma conta local.

Multiplos sistemas Unix com "winbind"

A forma como o "winbind" define os UIDs correspondentes aos SIDs dos novos utilizadores baseia-se num intervalo de valores estabelecido pelo administrador dentro do qual os UID vão sendo atribuidos à medida das necessidades. Isto significa que se existem vários sistemas Unix integrados num domínio Windows através do "winbind", não há qualquer garantia de que um dado utilizador vai ter o mesmo UID em todos os sistemas. Sob o ponto de vista de administração esta situação não é nada desejável, especialmente se os UID's têm um carácter permanente (winbind configurado para criar contas locais).

A forma mais simples de ultrapassar este problema consiste em optar pelo LDAP como base de dados para o Samba, nesse caso as equivalências SID/UID e SID/GID são armazenadas no servidor LDAP, se todos os servidores "winbind" utilizarem o mesmo servidor LDAP, então o problema desaparece. Quando um novo utilizador acede a um dos servidores Unix, será definido um UID e armazenado no servidor LDAP juntamente com o SID, ao aceder a um segundo servidor, o SID já está na base de dados e por isso será usado o mesmo UID.

"Software" Samba Cliente

O conjunto de "software" Samba inclui não apenas componentes que permitem transformar uma máquina Unix num servidor Windows, mas também aplicações clientes bastante úteis, de entre eles destacam-se:

• smbclient - permite o acesso a partilhas de servidores Windows ou Samba num estilo semelhante a um cliente FTP. As partilhas tanto podem corresponder a directórios como a impressoras.
• net - utilitário mais recente no qual estão a ser integradas a maioria da funcionalidades anteriormente dispersas por outros programas tais como o "rpcclient". Permite o acesso avançado a servidores Windows ou Samba remotos. As funções disponíveis incluem: gestão da base de dados de utilizadores e grupos; gestão de partilhas; gestão de filas de impressão; gestão de serviços; encerramento.
• smbcacls - este programa cliente permite a gestão das ACLs em servidores Windows remotos. De momento os outros clientes samba não têm a capacidade de trabalhar com as ACL do NTFS, para isso é necessário este programa separado. Pode ser usado por exemplo num "script" que percorre uma lista de máquinas windows para aplicar uma dada ACL em todas essas máquinas.

Sistema de impressão

O servidor Samba suporta as funcionalidades mais avançadas do sistema de impressão dos servidores Microsoft, nomeadamente a instalação automática de "drivers" nos clientes. Novamente para o fazer o Samba recorre ao sistema operativo local ou seja Unix. Assim as impressoras que um servidor Samba disponibiliza são as impressoras que estão definidas no sistema Unix, geralmente no ficheiro /etc/printcap.

Sob o ponto de vista cliente, o "smbclient" e o "smbspool" podem ser usados para acesso a impressoras partilhadas por sistemas Windows. Estes programas podem facilmente ser integrados no sistema de impressão do Unix, basta definir estas impressoras de forma apropriada no ficheiro "/etc/printcap" por forma a que os clientes apropriados (smbclient ou smbspool) sejam invocados.

Sistema de ficheiros de rede tipo "smbfs" e "cifs"

O protocolo de acesso aos sistemas de ficheiros partilhados pelos sistemas MS-Windows e Samba tem a designação CIFS ("Common Internet File System") e substitui a designação mais antiga SMB ("Server Message Block"). Os sistemas Linux mais recentes suportam a integração destes tipos de sistemas de ficheiros.

O "software" Samba inclui um programa auxiliar que permite aos sistemas operativos que suportam os tipos de sistemas de ficheiros CIFS e SMBFS incluir os mesmos no sistema de ficheiros através da operação "mount". O programa auxiliar tem o nome mount.smbfs ou mount.cifs (nas versões mais antigas o programa chamava-se smbmount).

Os programas auxiliares "mount.smbfs" ou "mount.cifs" são normalmente instalados no directório /sbin e são invocados pelo comando de sistema "mount" quando o tipo de sistema de ficheiros especificado é respectivamente "smbfs" ou "cifs".

Em Linux o suporte destes tipos de sistemas de ficheiros tem algumas limitações, a principal diz respeito ao controlo de acesso. Em Unix todos os sistemas de ficheiros deveriam ter ACLs Posix (permissões RWX para OWNER/GROUP/OTHERS), mas tal não é o caso dos sistemas de ficheiros CIFS nos quais as ACLs são totalmente diferentes. De momento o "mount.cifs" não suporta qualquer tipo de equivalência entre os dois tipos de ACL (ao contrário do que acontece com o servidor Samba).

Para contornar o problema da incompatibilidade entre ACLs, no acto da montagem de um sistema de ficheiros CIFS em Linux é necessário especificar:

• Username/Password - para estabelecer a sessão que será posteriormente usada para todas as operações sobre o sistema de ficheiros montado.
• UID - nome de utilizador a ser usado como OWNER de todos os ficheiros e directórios.
• GID - nome de grupo a ser usado como grupo a que pertencem todos os ficheiros e directórios.
• PERMISSÕES PARA FICHEIROS - permissões (Posix ACL) que todos os ficheiros irão ter.
• PERMISSÕES PARA DIRECTÓRIOS - permissões (Posix ACL) que todos os directórios irão ter.

Por outras palavras, todos os acessos ao sistema de ficheiros vão ser realizados com base na autenticação inicial, no acto da montagem. As ACL Posix que o sistema de ficheiros aparenta ter são definidas no acto de montagem e não pode ser alteradas posteriormente.

Como é obvio este modo de funcionamento coloca grandes problemas quanto à utilidade do "mount.cifs", normalmente o administrador Linux apenas disponibiliza sistemas de ficheiros deste tipo em modo "read-only".

Montagem CIFS pelos utilizadores

Embora a montagem de sistemas de ficheiros seja normalmente exclusiva do administratdor, essa limitação pode ser ultrapassada se o programa /sbin/mount.cifs tiver a permissão SETUID ROOT. Nesse caso os utilizadores poderão eles próprios executar o comando "mount" para aceder a sistemas de ficheiros CIFS, autenticando-se com o seu "Username/Password" próprios.

Extensões Unix do CIFS

O sistema de ficheiros CIFS tem diversos problemas de integração em Unix, um dos maiores diz respeito às ACLS, mas existem outros, por exemplo o CIFS não suporta ligações simbólicas, fundamentais aos sistemas Unix.

Quando o sistema servidor é do tipo MS-Windows nativo estes problemas são de dificil resolução, mas o mesmo não se passa se o servidor Windows funcionar sobre Unix (Ex.: servidor Samba), nesse caso as limitações derivam apenas do protocolo em sí.

Para resolver esta situação a HP desenvolveu uma especificação adicional, conhecida por "CIFS Unix Extensions" que permite ao protocolo "CIFS" suportar as ACL Posix (UID/GID/Permissões), e também tipos de entradas especiais caracteristas dos sistemas Unix tais como as ligações simbólicas. Tanto o servidor Samba como os vários clientes Samba suportam este complemento ao CIFS.