samba4 AD problema scrittura home utente o share in generale

[fieraf]

allora
io ho solo creato la share /ad_home (la root di tutte le cartelle utenti), la cartella dell'utente si crea automaticamente quando l'utente fa login la prima volta
pero effetivamente uid 10005 che vedi è dell'utente ciro e il 10003 é quello dell administartor
ho controllato nel rsat e non ci sono uid/gid doppi sia per utentei che per i gruppi domain admin . etc..
se ti riferisci a la share madre "Home" non voglio, come tu ben dicesti, que atri utenti possano eliminare o entrare nell home degli altri.
Ti riferisci a questo?

[luca33]

allora
io ho solo creato la share /ad_home (la root di tutte le cartelle utenti), la cartella dell'utente si crea automaticamente quando l'utente fa login la prima volta
pero effetivamente uid 10005 che vedi è dell'utente ciro e il 10003 é quello dell administartor
ho controllato nel rsat e non ci sono uid/gid doppi sia per utentei che per i gruppi domain admin . etc..
se ti riferisci a la share madre "Home" non voglio, come tu ben dicesti, que atri utenti possano eliminare o entrare nell home degli altri.
Ti riferisci a questo?

Mi riferisco a 2 cose in particolare...allora...
1-se guardi bene la Cartella "CIRO" che viene a sua volta creata nella share rooot "HOME" ha come proprietario un'utente con UID 10003 cioè in questo caso "administrator" che fa parte di default del gruppo "Domain Admins" e "Domain Users"...questo non è corretto xk l'utente che al primo login crea la cartella home con il suo nome utente deve necessariamente avere come proprietario l'UID 10005 ed il suo GID che è il gruppo di appartenenza predefinito.Il fatto che tu veda questi UID/GID assegnati corettamente solo tramite le ACL ciò non significa che il tutto funzioni corettamente...cioè sia i permessi in stile POSIX che i permessi tramite ACL devono combaciare...a farla breve, POSIX (Proprietario:Gruppo:altri<--solitamente non deve possedere nessun permesso, ad esclusione di alcuni casi particolari) ed ACL devono avere L'UID/GID sincronizzati per quanto riguarda proprietario e gruppo...Non va fatta cmq eccezione anche quando le ACL hanno più impostazioni di permessi; vale sempre la stessa regola.

2-Se fai un'attenta analisi dei permessi che hai impostato nella share root "HOME" Tramite la TAB Sicurezza il gruppo "Domain Users" ha solo ed esclusivamente il permesso di Visualizzare il contenuto della cartella e nient'altro...quindi in via teorica quando un'utente appartenente al gruppo "Domain Users" accede a quella share avrebbe solo il permesso di visualizzare il contenuto di quella cartella e nient'altro...cioè non sarebbe in grado di modificare/eliminare creare ulteriori oggetti figli (cartelle o file)...detto questo se ci pensi bene le ACL che hai impostato al gruppo dovrebbero fare quanto detto sopra...ma in realtà non lo fanno o lo fanno solo in parte...è vero che gli utenti non possono entrare/cancellare le cartelle degli altri utenti...ma il controsenso è che non dovrebbero permettere nemmeno la creazione della cartella "HOME' dell'utente che effettua il login...quindi a mio parere effettivamente c'è qualche cosa che non funziona correttamente...oppure gli utenti fanno parte di qualche gruppo che ha permessi più elevati vedi "Domain Admins"...tieni presente che le ACL lavorano per eredetarietà...quindi tutti i permessi impostati nella share di root veranno ereditati dagli oggetti figli...Fa eccezione se manualmente vai a modificare i permessi di un'ogetto figlio togliendo però l'eredetarietà da quell'oggetto in giù...ricorda di applicare xrò anche agli ulteriori oggetti figli del precedente oggetto figlio (che in questo caso diventerà una nuovo "Sub-Root" nel caso di una cartella) tramite l'apposito flag...infine ti consiglio di dare un'occhio anche al gruppo POSIX (non Windows)che è stato impostato di default per quell'utente da RSAT...ricorda infine che in fase di progetto l'assegnazione corretta dei gruppi di appartenenza ed gli eventuali permessi per ogni share della rete; è un lavoro lungo e meticoloso e ben programmato. Ma questo ti eviterà in futuro centinaia di problematiche.
Attendo riscontri
Ciao
Luca

[fieraf]

ciao
Ho risolto tutto montando un samba AD member come hai fatto tu.
ho creato le share dei profili e le home.
le cartelle tanto quelle dei profili que delle home vengono creati con il nome utente che fa il login e il gruppo domain users
ho reso no browseable entrambe le share per evitare "impiccioni"
alla fine credo que pero impostare i permessi posix sia la migliore scelta per linux.
A mio avviso pemette fare molto piú cose que con rsat di microsoft
grazie per tutte le dirtitte
P.s: per comprovare que ho ben configurato l'AD member, credo di si perché posso vedere i gruppi e gli utenti del AD master,hai qualche link da podermi passare ?

[luca33]

ciao
Ho risolto tutto montando un samba AD member come hai fatto tu.
ho creato le share dei profili e le home.
le cartelle tanto quelle dei profili que delle home vengono creati con il nome utente che fa il login e il gruppo domain users
ho reso no browseable entrambe le share per evitare "impiccioni"

ottimo...hai fatto la scelta migliore a separare il file dal DC al server membro...hai anche installato e configurato le PAM e WINBIND x caso?

[fieraf]

in realta questa parte non funzionava bene seguendo il wiki perche la cartella /lib64/security non esiste e quindi non posso seguire.
Ho provato a crearla manualmente e non va.Di fatto dovetti reinstallare il server perche non potetvo piu accedere alla macchina.
se puoi indicarmi come farlo, é gradito.
Ma a cosa serve in particolare?
in tutti i modi dal server AD MASTER posso fare login attraverso ssh al AD member

[fieraf]

apro un altro post per quet'argomento

[luca33]

in realta questa parte non funzionava bene seguendo il wiki perche la cartella /lib64/security non esiste e quindi non posso seguire.
Ho provato a crearla manualmente e non va.Di fatto dovetti reinstallare il server perche non potetvo piu accedere alla macchina.
se puoi indicarmi come farlo, é gradito.
Ma a cosa serve in particolare?
in tutti i modi dal server AD MASTER posso fare login attraverso ssh al AD member

esatto...ma in configurando le PAM insieme a WINBIND hai la possibilità di effettuare il login via shell o ssh usando gli account utente in AD...almeno che tu non abbia decine e decine di server da gestire ognuno con un'utente e password diversi per la gestione locale...beh in questo caso la centralizzazione su AD è d'obbligo...ma se hai un paio te lo sconsiglio vivamente...per 2 motivi:
1)-Se ci fosse qualche cosa che non funziona correttamente....ci potrebbero essere seri problemi ad effettuare il login dalla shell.
2)-E'possibile che x un'errore umano e una distrazione dimentichi di modificare la shell di default assegnata automaticamente ad un'utente standard (non di gestione) su AD questo però comporta un po di grattacapi alla sicurezza xkè darà la possibilità di accedere direttamente alla console locale del server.
Quindi se proprio non ti serve scarta a priori la configurazione delle PAM.

Per quando riguarda WINBND invece serve a MAPPARE gli utenti/gruppi presenti su AD in modo che siano visti dal sistema come utenti locali. Ma non solo;
-consente la risoluzione corretta dei nomi degli account dell'utente/ gruppo e la loro appartenenza ad essi (Es: "Domain Users"), contiene il percorso della shell di default da usare per il login su sistemi *NIX e il percorso della directory home di ogni utente.

Esempio:
Se sul server membro hai bisogno di assegnare un nuovo proprietario/gruppo in stile POSIX (o anche tramite ACL) con degli utenti presenti su AD ad una nuova directory (es: /prova), con WINBIND correttamente configurato basterà scrivere:

Codice: Seleziona tutto

chown utenteAD:"gruppo di AD" 

Tieni presente che la configurazione delle PAM per funzionare necessita assolutamente di WINBIND cosa invece inversa se si vuole solo mappare correttamente i nomi per un server membro che faccia da solo FILE SERVER.
Concludo dicendo che per un Buon Funzionamento di un server membro è necessario che WINBIND sia installato e funzioni a dovere. per quanto riguarda PAM invece il setup è un po ostico ma fornisce dei vantaggi con certamente i suoi rischi. Spero di averti chiarito i dubbi.

Luca