Samba, AD et Kerberos
Samba, AD et Kerberos - Logiciels - Linux et OS Alternatifs
Marsh Posté le 28-09-2005 à 16:30:33
Hello,
En fait, est-ce que c'est vraiment nécessaire d'utiliser le mode security = ADS de Samba?
Puisque Winbind et les ACL tournent de toute façon sans cela...
Parce que vu la configuration minimaliste de l'installation (2 serveurs, une vingtaine de stations), je ne pense pas qu'il soit nécessaire d'être en mode "ultra paranoïaque" sur la sécurité des partages...
Est-ce qu'avoir le mode security = user ne suffit pas pour filtrer les utilisateurs sur les partages?
Est-ce qu'avec ce mode de partage les ACL sur le filesystem Unix peuvent être modifiées par un administrateur du domaine depuis un client Windows au travers du dît partage?
Merci.
Marsh Posté le 28-09-2005 à 18:08:59
tu peux poster ton smb.conf et krb5.conf ?
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 29-09-2005 à 12:23:45
Salut Dark,
Yep! Les voilà:
krb5.conf (les noms sont faux, la casse est respectée):
[libdefaults] |
smb.conf:
|
Marsh Posté le 29-09-2005 à 15:43:00
| Citation : |
tu es sûr pour cette partie ?
que donne klist tickets surtout lorsque cela merde ?
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 29-09-2005 à 16:24:47
| Dark_Schneider a écrit : [quote]que donne klist tickets surtout lorsque cela merde ? |
C'est intéressant! J'en étais là de mes recherches... Comme je disais je pressens confusément qu'il y a une histoire de tickets Kerberos mal gaulés...
Alors, question de newbie sur Kerberos: Tu me demandes le résultat d'un klist tickets sur le Windows 2003 server ou bien sur le Linux?
Car sur Linux, klist, 'tickets' n'existe pas comme option... Et sur le Windows, y a pas du tout de commande klist.exe???!!! Meuh?
Y a-t-il une commande "graphique" (console ou outils d'administration) qui exporterait les tickets enregistrés sur le Windows?
Marsh Posté le 03-10-2005 à 11:49:48
Salut,
J'ai un début de réponse à mes soucis!!!
1) En ajoutant quelques lignes au krb5.conf, il semble qu'on évite des déconnexions intempestives.
[libdefaults] |
Je suppose que les 2 dernières lignes pratiquent un aliasing au niveau des noms réseaux pour qu'il y ait des traductions dans tous les sens entre FQDN et pas FQDN. De manière à tt le temps arriver sur MYDOMAIN.DOM, puisque Kerberos le veut comme ça.
2) Ensuite, pour les problèmes d'identification de Samba, c'est à la fois beaucoup plus trivial: Samba n'y est pour rien, c'est déjà ça! Et c'est à la fois plus compliqué à "curer"...
En fait, dans la session de certains utilisateurs, lorsqu'ils n'arrivaient pas à se connecter et que Windows leur proposait la boîte d'identification, ces utilisateurs avaient coché la case "Mémoriser mon mot de passe"... 
A partir de là, on a beau se déconnecter et se reconnecter, dès qu'on double-clique sur le serveur qui nous intéresse, on est identifié NON PAS PAR SON ID DU DOMAINE, mais PAR LES CONNERIES QU'ILS ONT ENTRE DANS LA BOITE D'IDENTIFICATION... 
Ca vaut la peine d'être dans un domaine... Si c'est pour que les boîtes d'identification sauce W95 prennent le dessus quand il y a un pb d'autentification...
Donc, après quelques recherches à l'aide de regmon et filemon (Sysinternals Free Tools), je sèche... Je ne pige pas où cet abruti de système range ces infos d'identification falacieuses...
Est-ce que quelqu'un sait comment purger ces ident du profil de l'utilisateur?
Merci d'avance.
Mikee
Message édité par mikeleetoris le 03-10-2005 à 12:35:15
Marsh Posté le 03-10-2005 à 12:52:15
tu avais des bécanes win9x ? lol.
je ne peux pas t'aider pour le pb avec win9x. cependant dans clic droit sur voisinage réseau -> propriétés, il y a certains trucs que tu peux cocher ou décocher/enlever comme par exemple poste de travail ( car tu as besoin avant tout de "client ...." ). Mais bon win9x n'est pas fait pour cela et ce même en ajoutant le pack pour support ActiveDirectory.
Upgrade tes bécanes, passe en win2k, surtout que win9x n'est plus supportée.
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 03-10-2005 à 13:04:15
| Dark_Schneider a écrit : tu avais des bécanes win9x ? lol. |
Heu non non!!! Tous mes postes clients sont en XP SP2!!!
C'est pour cela que je disais "sauce W95".
Mais là, comprend pô où il va ranger ses infos...
Regmon me montre surtout des accès à HKCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU... Qui contiennent un subtil mélange de chemins réseau en ASCII passé en binaire??? Berk!
Filemon me montre des accès à C:\Windows\WinSxS\Manifest avec aussi des trucs imbitables dedans...
Y a pas une gestion de "trousseau de clés"? Qui serait stocké dans le profil de l'utilisateur?
Genre dans "[Profil]\Application data\Microsoft\Credentials"?
Marsh Posté le 03-10-2005 à 13:09:10
vraiment bizarre cette histoire de boite de dialogue avec enregistrement de mot de passe si ton win est conf pour s'auth sur un domaine ...
c'est du Pro ou du familiale ?
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 03-10-2005 à 13:29:24
| Dark_Schneider a écrit : c'est du Pro ou du familiale ? |
Du pro... Avec un W2003 serveur.
Mais n'oublie pas que, même la station étant dans le domaine, c'était quand Samba déconnait que cette boîte de dialogue se montrait.
En fait, tu as exactement le même effet lorsque tu te logues sur une machine du DOMAINE, mais en Administrateur LOCAL. Si ensuite tu accèdes à un répertoire partagé dans le DOMAINE (serveur Samba), il te demande qui tu es. Là, c'est normal.
Le souci, donc, c'est que Samba déconnait, les utilisateurs, bien qu'identifiés (session loguée) dans le DOMAINE, étaient vu comme des "estrangers" par le serveur, Windows affiche alors cette boîte d'ident réseau, et les utilisateurs y ont entré des noms et des mots de passe sans rapport avec leur vrai login DOMAINE, en cochant "mémoriser"... Bouhouhou!
Bref... Un beau bordel est donc maintenant stocké qque part dans Windows ou leur base de registre...
Là, j'ai cru trouver un début de résolution, mais cela ne marche pas sur tous les utilisateurs.
En dégageant le répertoire [Profil]\Local Settings\Application Data\Microsoft\Windows qui contient UsrClass.dat et UsrClass.log (un bout de base de registre user), cela a fonctionné chez un user. On a retrouvé le réseau comme y faut! 
Sauf que chez un autre... Même en supprimant son UsrClass.dat, même en "bougeant" son profil pour que Windows en recréer un nouveau, la personne reste identifiée par le nom incorrect qu'elle avait entré dans la boîte de dialogue... Là, ça sent le gremlins... On dirait que c'est stocké au niveau machine et non plus user... Et pourtant, comme dirait Spok: Illogique!
Ah oui: Dernière précision: Les profiles NE SONT PAS itinérants (pour le moment). Chaque utilisateur restant sur sa machine, ça n'est pas très important que le profile se ballade. Donc, il n'y a rien à aller effacer sur le serveur d'abord avant que l'utilisateur ne se logue.
Message édité par mikeleetoris le 03-10-2005 à 13:54:43
Marsh Posté le 03-10-2005 à 14:59:44
c'est peut être cela le problème ... que les profils ne soient pas itinérants ... ils seraient itinérant, ta modif lmarcherait tout le temps car faite dans le ntuser.dat ( ou plutôt ntduser.man ).
sinon check que tu n'as pas "reconnecter les lecteurs réseau au démarrage"
dans les scripts de connexion tu peux forcer la déconnexion et reconnexion du lecteur réseau
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 11-10-2005 à 02:43:50
Salut,
| Dark_Schneider a écrit : c'est peut être cela le problème ... que les profils ne soient pas itinérants... |
Ben non... Ce n'était pas dû au fait d'être en profil itinérant ou pas! C'était bien dû au fait que certains utilisateurs avaient cochés la case "mémoriser mon mot de passe" lors d'un accès réseau en tant qu'administrateur local...
J'ai compris où était rangé ce mot de passe (sous XP: panneau de configuration, utilisateur, options avancées, mots de passe enregistrés, liste => SUPPRIMER!!!)
Sauf que, là où ça pue gravement le bug d'accès au réseau, il faudrait m'expliquer POURQUOI un mot de passe réseau, saisi en tant qu'administrateur local, prend la main sur l'identification d'un utilisateur lambda, du domaine ou pas... C'est du grand n'importe quoi!!!
Exemple: Je suis logué en admin local, je veux accéder à un partage réservé aux membres du domaine pour faire une install, il me demande mon identité, Toto, ok. Si je coche "mémoriser mon mot de passe", lorsque je me logue dans un autre utilisateur, Titi, le serveur m'identifie sans me demander quoique ce soit comme... Toto! Et non pas Titi... 
Il est normal que des réglages effectués en tant qu'admin local influe sur le système et les autres utilisateurs, mais l'identification réseau locale qui passe avant l'identification du domaine, ça c'est raide...
Pas mal non plus: Si un utilisateur du domaine, Titi, essaye de se loguer sur un partage auquel il n'a pas le droit, le serveur demande l'identité, on tape Toto et on mémorise le mot de passe. Après, les accès sont aussi faits en tant que... Toto. Mais là c'est normal. Sauf que!!! Pour enlever ce mot de passe foireux, si l'on va dans panneau de config, utilisateur, mots de passe, on ne voit pas l'utilisateur du domaine, Titi!!! Puisque c'est la gestion des trousseaux de clés des utilisateurs LOCAUX!!! Ha! Ha! Ha! Elle est bien bonne!!! Pour arriver à l'enlever j'ai été obligé de déclarer l'utilisateur du DOMAINE (Titi) comme faisant partie du groupe des admins LOCAUX de sa machine... Là, on voit l'utilisateur du DOMAINE dans les utilisateurs LOCAUX et on peut saquer les mots de passe inopportuns. Donc, c'est un bon gag, un utilisateur du DOMAINE stocke ses trousseaux de clés en LOCAL, mais il n'a pas le droit d'y accéder tant qu'il ne fait pas partie des utilisateurs LOCAUX... Arf! Arf!
C'est reproductible. Vous pouvez "jouer"!!!
Donc, Samba n'y est pour rien du tout!!!
Marsh Posté le 11-10-2005 à 16:48:21
vive windows.
cependant, si tu fais un partage sur le win2k3, est ce que tu peux reproduire la même chose ? ( mix mot de passe domaine/locaux )
---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Marsh Posté le 06-04-2006 à 16:19:53
Salut a tous,
je reprend le topic car je me retrouve dans un cas voisin.
TOPOLOGIE:
Mon LAN fait partir du Domaine de mon entreprise reparti a travers plusieurs villes dans tous le pays.
Le nom de domaine est FRANCE-CORP.
Les noms DNS suivent ensuite une hierarchie par ville.
Le nom DNS de la machine X a Toulouse sera: machineX.toul.france.corp, la machine Y a Marseille sera machineY.mars.france.corp, ainsi de suite.
Chaque LAN (chaque bureau ~ chaque ville) possede son propre Domain Controler sur le LAN.
Par ex, controler.mars.france.corp pour le DC a Marseille.
OBJECTIF:
J'ai une Debian que j'utilise pour faire de la supervision reseau sur un LAN en particulier (par exemple Toulouse)
Je souhaiterai integrer cette machine a l'Active Directory.
J'ai suivi le tuto donne par Debian Admin ici: http://www.debian-administration.org/articles/340
Mais lorsque je tape
Code :
|
, je recois le message:
Code :
|
Une idee sur la source du probleme ? Sur le debuggage ?
Merci
Marsh Posté le 06-04-2006 à 16:20:55
Dsl, double envoi
Message édité par rld le 07-04-2006 à 09:01:42
Marsh Posté le 06-04-2006 à 16:23:57
dsl, triple envoi
Message édité par rld le 07-04-2006 à 09:01:18
Marsh Posté le 07-04-2006 à 09:23:31
Un probleme resolu, il fallait en fait taper:
Code :
|
Je peux faire le
Code :
|
apres pour verifier le ticket.
Par contre le
Code :
|
ne fonctionne pas...
Sujets relatifs:
- probleme avec le serveur samba
- integration reseau NT avec samba
- [SAMBA] archive bit impossible à effacer?
- [Trustix] Obtenir un acces au serveur Samba depuis une station windows
- Authentification postes linux avec PDC samba / openldap
- samba et nom de machine
- Configuration de Samba
Marsh Posté le 27-09-2005 à 03:30:10
Bonjour,
Je suis un site en cours d'installation.
J'ai un Windows 2003 Serveur avec AD et DNS pour gérer mes users, groupes, GPO, etc.
J'ai un Suse 9.3 Pro comme serveur de fichiers. Avec Samba 3.0.13, Winbind, Kerberos 1.4-16.4 (install par défaut, puis mise à jour packages en ligne).
On a des gros pb de stabilité sur l'identification des stations et/ou des users par Samba...
Cela fait à peu près cinq jours que je cherche des infos sur le net! Dans ce qui est présenté, le souci c'est de faire une synthèse du contenu minimaliste des fichiers de conf pour avoir une base de solution fonctionnelle!!! Quitte à complexifier les fichiers de conf par la suite.
Je vois pas mal de pages avec les mêmes erreurs que j'ai dans le log.smbd, donc je ne suis pas seul, mais il n'y a pas vraiment de solution unique proposée.
Si je puis résumer ce qui se passe:
nsswitch.conf: passwd et group avec winbind, ok.
resolv.conf: pointe sur le serveur Windows DNS et AD, ok.
krb5.conf: minimaliste tel que décrit chez m'sieur Samba.
smb.conf: ok, tel que décrit chez m'sieur Samba (et plein d'autres...)
pam.d/samba: ok, tel que décrit chez m'sieur Samba.
source principale:
http://us1.samba.org/samba/docs/ma [...] ads-member
http://gentoo-wiki.com/HOWTO_Addin [...] _AD_Domain
winbind fonctionne: wbinfo -u, wbinfo -g, getent passwd, getent group renvoient les bonnes infos.
net ads join admin@mydomain s'est passé correctement.
net ads status me dit que je suis bien dans le domaine et que le serveur répond.
kinit sur différents users renvoie bien un ticket valide.
Mais sur les clients XP, une fois un user logué sur le domaine, on a un comportement erratique sur les partages Samba:
-- Parfois, tout est accessible, le home directory est bien montré et browseable.
-- Parfois, les partages sont accessibles pendant plusieurs minutes, puis paf, cela redemande user et mot de passe pour accès.
-- Parfois, après le login, les partages sont là, mais pas le home directory et rien n'est accessible sans mot de passe.
-- Lorsqu'il redemande le mot de passe, parfois il accepte une notation mydomain\user, parfois il s'en fout! Parfois il accepte une notation mydomain.dom\user (FQDN)...
-- Il redemande un login/password y compris sur des partages qui sont "public = Yes"???
Lorsque les partages sont ou deviennent inaccessibles, dans le fichier log.smbd on voit des lignes comme ceci:
[2005/09/27 02:05:18, 2] smbd/sesssetup.c:setup_new_vc_session(608)
setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.
[2005/09/27 02:05:18, 1] smbd/sesssetup.c:reply_spnego_kerberos(250)
Username MYDOMAIN+user is invalid on this system
Parfois des lignes comme ceci, où l'utilisateur est sans son nom de domaine alors qu'il est bien logué dans le domaine sur sa station:
[2005/09/26 19:27:57, 2] auth/auth.c:check_ntlm_password(312)
check_ntlm_password: Authentication for user [user] -> [user] FAILED with error NT_STATUS_NO_SUCH_USER
Parfois ce ne sont pas les users qui sont marqués "invalid", mais les stations:
[2005/09/27 02:02:10, 1] smbd/sesssetup.c:reply_spnego_kerberos(250)
Username MYDOMAIN+station$ is invalid on this system
........ Groumpf! ......... Alors que getent renvoie toujours correctement la liste des users et des stations...
Le pire étant pour les utilisateurs d'avoir les accès en début de session (login domaine) et de se faire jeter en cours de route. Surtout qu'ils ont beau ré-entré leur login/password, cela ne fonctionne pas...
En fermant la session utilisateur, puis en rouvrant la même, cela ne fonctionne pas mieux.
En changeant d'utilisateur sur la même machine, parfois cela fonctionne, parfois pas
Souvent, le mieux est de redémarrer le système et de reloguer l'utilisateur...
C'est donc totalement casse-c........
Les serveurs sont synchros en terme d'horloge, il n'y a donc pas de "horloge skew too great"!
Je soupçonne deux problèmes qui ne sont pas forcément antagonistes:
1) Pb de tickets Kerberos qui seraient soit mal attribués, soit d'une durée de vie tout à fait ridicule, mais le fait d'ajouter une option ticket_lifetime = 24000 par exemple dans le /etc/krb5.conf ne change rien...
2) Pb de reconnaissance sur le nom de domaine. J'ai bien compris que Kerberos était très chatouilleux sur la casse, mais même avec des options comme suit, cela ne change rien...
.mydomain.dom = MYDOMAIN.DOM
.server-ad.mydomain.dom = MYDOMAIN.DOM
mydomain.dom = MYDOMAIN.DOM
server-ad.mydomain.dom = MYDOMAIN.DOM
Argl! Au se-cou-reuh!!! Est-ce que quelqu'un aurait une piste?!
Non parce que là, j'ai un peu l'impression de tourner en boucle en essayant des options selon les pages web que je trouve, il me manque une synthèse!!! Si ça se trouve, je suis passé à côté de l'option qui tue, toute simple!!!
Merci par avance.
Mikee