Perfis de roaming internos no servidor samba confiável de região?

1

Raison D'être

Eu estou tentando, até agora sem sucesso, armazenar perfis móveis para um domínio do Active Directory em um servidor de arquivos ZFS-on-Linux do Ubuntu 12.04LTS confiável. O objetivo final é ter um servidor de arquivos interoperável para abrigar diretórios iniciais do autofs nfs para Linux e perfis móveis para Windows. É politicamente difícil para mim fazer isso apenas com o Windows Servers ou unir servidores Linux ao Active Directory. Como tal, estou procurando soluções técnicas ou provas de que tais soluções técnicas são menos defensáveis do que a luta de batalhas políticas.

Eu suspeito que a minha dificuldade atual tem algo a ver com o cliente do Windows para interações samba em vez de zfs, mas estou um pouco fora do meu fundo, então eu não estou decidindo completamente. Você poderia, caro leitor, apontar porque o que estou fazendo é incorreto e explicar o procedimento correto?

O que eu acho que sei

  1. O usuário pode efetuar login com êxito na máquina cliente a partir do domínio kerberos. No entanto, o usuário está logado com um perfil temporário.
  2. Uma pasta de perfil é criada (presumivelmente pelo processo de login) no servidor de arquivos, mas nenhum outro arquivo é criado nessa pasta de perfil recém-criada.
  3. A pasta do perfil é criada automaticamente com o proprietário / grupo adequado.
  4. Devido a isso, parece improvável que o perfil seja carregado antes que o cache de credenciais seja instanciado ou o krbtgt seja concedido.
  5. Durante o login no perfil temporário, o usuário pode criar arquivos no servidor de arquivos sem precisar fornecer ao servidor de arquivos quaisquer credenciais (adicionais). Isso é que não há prompt. Esses arquivos também são criados com o proprietário / grupo apropriado.

Informações adicionais

Esta é toda a configuração que eu acho que você vai querer saber, mas eu posso estar errado. Peço desculpas por não encontrar uma maneira de que seja desmontável.

Uma breve visão geral dos sistemas e máquinas envolvidos

AD domain: ad.example.com  (Functional Level 2012)
domain controllers: dc1.ad.example.com, dc2.ad.example.com (OS: Windows Server 2012 Std)
mit-krb5 realm: EXAMPLE.COM  
mit-krb5 kdcs: kdc1.example.com, kdc2.example.com (mit-krb5: 1.9.4)
smb/cifs server: zfs.example.com  (OS: Ubuntu 12.04LTS)
client: client.ad.example.com (OS: Windows 8 Enterprise)

O registro do Samba

root@zfs:~# cat /var/log/samba/client.log
[2013/06/14 14:37:26.194496,  0] param/loadparm.c:9114(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/tank_test failed. Permission denied
[2013/06/14 14:37:26.460344,  0] param/loadparm.c:9114(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/tank_test failed. Permission denied
[2013/06/14 14:44:04.352344,  0] param/loadparm.c:9114(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/tank_test failed. Permission denied

Não tenho certeza sobre o que está reclamando ...

root@zfs:~# ls -l /var/lib/samba/usershares/tank_test
-rw-r--r-- 1 root root 110 Jun 14 12:57 /var/lib/samba/usershares/tank_test

O pré-login de compartilhamento do servidor de arquivos

root@zfs:~# ls -la /tank/test/
total 38
drwxrwxrwt 2 root root 2 Jun 14 09:12 .
drwxr-xr-x 5 root root 5 Jun 13 15:52 ..

Compartilhamento de servidor de arquivos pós-login:

root@zfs:~# ls -la /tank/test/
total 57
drwxrwxrwt 3 root root 3 Jun 14 09:16 .
drwxr-xr-x 5 root root 5 Jun 13 15:52 ..
drwxr-xr-x 2 user user 2 Jun 14 09:16 user.V2
root@zfs:~# find /tank/test
/tank/test
/tank/test/user.V2/

Cache de credencial do usuário no login

Current LogonId is 0:0x6c79e3

Cached Tickets: (7)

#0> Client: user @ EXAMPLE.COM
    Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x60a90000 -> forwardable forwarded renewable pre_authent name_canonicalize 0x80000
    Start Time: 6/14/2013 14:44:24 (local)
    End Time:   6/15/2013 2:44:24 (local)
    Renew Time: 6/21/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0x2 -> DELEGATION 
    Kdc Called: kdc2.example.com

#1> Client: user @ EXAMPLE.COM
    Server: krbtgt/AD.EXAMPLE.COM @ EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
    Start Time: 6/14/2013 14:44:24 (local)
    End Time:   6/15/2013 2:44:24 (local)
    Renew Time: 6/14/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0 
    Kdc Called: kdc2.example.com

#2> Client: user @ EXAMPLE.COM
    Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize 
    Start Time: 6/14/2013 14:44:24 (local)
    End Time:   6/15/2013 2:44:24 (local)
    Renew Time: 6/21/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0x1 -> PRIMARY 
    Kdc Called: kdc2.example.com

#3> Client: user @ EXAMPLE.COM
    Server: ldap/dc1.ad.example.com @ AD.EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize 
    Start Time: 6/14/2013 14:44:31 (local)
    End Time:   6/15/2013 0:44:31 (local)
    Renew Time: 6/14/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0 
    Kdc Called: dc1.ad.example.com

#4> Client: user @ EXAMPLE.COM
    Server: LDAP/dc1.ad.example.com/ad.example.com @ AD.EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize 
    Start Time: 6/14/2013 14:44:25 (local)
    End Time:   6/15/2013 0:44:25 (local)
    Renew Time: 6/14/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0 
    Kdc Called: dc1.ad.example.com

#5> Client: user @ EXAMPLE.COM
    Server: cifs/dc1.ad.example.com @ AD.EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize 
    Start Time: 6/14/2013 14:44:24 (local)
    End Time:   6/15/2013 0:44:24 (local)
    Renew Time: 6/14/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0 
    Kdc Called: dc1.ad.example.com

#6> Client: user @ EXAMPLE.COM
    Server: cifs/zfs.example.com @ EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
    Start Time: 6/14/2013 14:44:24 (local)
    End Time:   6/15/2013 2:44:24 (local)
    Renew Time: 6/14/2013 14:44:24 (local)
    Session Key Type: AES-256-CTS-HMAC-SHA1-96
    Cache Flags: 0 
    Kdc Called: kdc2.example.com

A confiança no REALM

ldapsearch -h ad.example.com -LLL cn=EXAMPLE.COM  objectClass trustPartner instancetype trustDirection trustAttributes
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
dn: CN=EXAMPLE.COM,CN=System,DC=ad,DC=example,DC=com
objectClass: top
objectClass: leaf
objectClass: trustedDomain
instanceType: 4
trustDirection: 3
trustPartner: EXAMPLE.COM
trustAttributes: 1

O usuário do Active Directory

ldapsearch -h ad.example.com -LLL samaccountname=user profilePath altSecurityIdentities
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
dn: CN=Test User,OU=managed users,DC=ad,DC=example,DC=com
profilePath: \zfs.example.com\tank_test\user
altSecurityIdentities: Kerberos:[email protected]

As informações básicas do ZFS

root@zfs:~#  zfs get mountpoint,casesensitivity,sharesmb,available tank/test
NAME       PROPERTY         VALUE        SOURCE
tank/test  mountpoint       /tank/test   default
tank/test  casesensitivity  mixed        -
tank/test  sharesmb         on           local
tank/test  available        26.1T        -

O ZFS criou o compartilhamento de smb     root @ zfs: ~ # cat / var / lib / samba / usershares / tank_test     #VERSÃO 2     caminho = / tanque / teste     comment = Comentário: / tank / test     usershare_acl = S-1-1-0: F     guest_ok = n     nome_do_compartilhamento = tank_test

A configuração do Samba

root@zfs:~# grep -v -e ^$ -e ^\; -e ^# /etc/samba/smb.conf
[global]
   workgroup = EXAMPLE.COM
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/%M.log
   max log size = 1000
   syslog = 3
   panic action = /usr/share/samba/panic-action %d
security = ADS
realm = EXAMPLE.COM
kerberos method = system keytab
map to guest = bad user

A tabela de teclas do servidor de arquivos

root@zfs:~# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2  host/[email protected] (aes256-cts-hmac-sha1-96)
   2    2  host/[email protected] (aes128-cts-hmac-sha1-96)
   3    2  host/[email protected] (arcfour-hmac)
   4    2   nfs/[email protected] (aes256-cts-hmac-sha1-96)
   5    2   nfs/[email protected] (aes128-cts-hmac-sha1-96)
   6    2   nfs/[email protected] (arcfour-hmac)
   7    2  cifs/[email protected] (aes256-cts-hmac-sha1-96)
   8    2  cifs/[email protected] (aes128-cts-hmac-sha1-96)
   9    2  cifs/[email protected] (arcfour-hmac)

O mapeamento de identidade do servidor (via sssd)

root@zfs:~# cat /etc/sssd/sssd.conf
# SSSD configuration generated using /usr/lib/sssd/generate-config
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = example.com
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/example.com]
enumerate = false
cache_credentials = true
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
krb5_kdcip = kerberos.example.com
krb5_realm = EXAMPLE.COM
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15

Pacotes do servidor (Relavent)

root@zfs:~# uname -a
Linux zfs 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@zfs:~# dpkg --get-selections | grep -e samba -e zfs -e krb -e sssd
krb5-config                                     install
krb5-locales                                    install
krb5-user                                       install
libgssapi-krb5-2                                install
libkrb5-26-heimdal                              install
libkrb5-3                                       install
libkrb5support0                                 install
libpam-krb5                                     install
libzfs1                                         install
samba                                           install
samba-common                                    install
samba-common-bin                                install
samba-tools                                     install
sssd                                            install
ubuntu-zfs                                      install
zfs-dkms                                        install
zfsutils                                        install
    
por 84104 15.06.2013 / 00:28

1 resposta

1

Por padrão, os clientes Windows devem verificar as pastas de perfil de roaming ACLs usando SIDs ao carregar os perfis de roaming. Mesmo ter o usuário Active Directory com o mesmo atributo uid , uidNumber , gidNumber e um atributo altSecurityIdentites adequado é insuficiente.

Enquanto o requisito do SID não pode ser desativado. A verificação ACL em si pode ser. A pasta ainda deve ser legível pelo usuário ou pelo grupo Administradores.
No Server 2012, essa política é chamada de Do not check for user ownership of Roaming Profile Folders
e é encontrado em Computuer Configuration \ Administrative Templates \ System \ User Profiles

Eu deveria ter olhado os logs do cliente Windows anteriormente; Eu não tenho desculpa para isso.

log do Windows: Windows could not load your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you log off. Windows could not load your profile because a server copy of the profile folder already exists that does not have the correct security. Either the current user or the Administrators group must be the owner of the folder.

    
por 21.06.2013 / 19:25