Publication d’un nouveau support de cours -> SAMBA 3.6 avec Red Hat Enterprise Linux

Publié le 30 juin 2013 par Guillaume Mathieu

Bonjour

Je viens de terminer la première version du support de cours sur SAMBA. Le document peut être téléchargé à l’adresse suivante :
http://msreport.free.fr/articles/SAMBA_RedHatEnterpriseLinux.pdf
Les éléments suivant sont abordés dans ce document. N’hésitez pas à m’envoyer vos retours d’expériences…

1. Présentation de l’architecture cible
– Vue d’ensemble de l’architecture OpenLDAP / Samba
– Présentation des composants de l’authentification sur un serveur Linux (PAM…)

2. Installation et configuration de Red Hat Enterprise Linux
– L’activation, désactivation du pare feu et de SE Linux

3. Procédure de déploiement
– Installation d’OpenLDAP
– Configuration OpenLDAP
– Configuration du serveur de temps sur les contrôleurs de domaine SAMBA
– Configuration du serveur de temps sur les machines Windows
– Configuration de SAMBA
– Configuration de SMBLDAP-TOOLS
– Configuration du service SSSD
– Configuration de la résolution WINS
– Configuration des scripts de login
– Configuration du secrit de login
– Configuration des stratégies de mots de passe
– Configuration des machines Windows XP / Windows 7
– Configuration de SAMBA en tant que serveurs de fichiers
– Configuration de SAMBA en tant que serveurs d’impression

4. Procédures d’administration
– Vue d’ensemble des principaux outils d’administration de SAMBA

Bonne lecture.

A+
Guillaume MATHIEU
Consultant PROSERVIA
La connaissance s’accroît quand on la partage

Publié dans Annuaire, Linux, SAMBA, Windows Seven, Windows XP | Laisser un commentaire

Dépannage NTFRS avancé.

Publié le 9 avril 2013 par Guillaume Mathieu

Bonjour

Ci-dessous le descriptif d’un incident NTFRS que j’ai rencontré chez un de mes clients.

ARCHITECTURE CLIENT :
Un domaine Active Directory MSREPORT.INTRA géré par 3 contrôleurs de domaine sous Windows 2003 SP2 FR.

DESCRIPTION DE L’INCIDENT :
Le contenu des partages \\msreport.intra\sysvol (C:\WINDOWS\SYSVOL\SYSVOL\) et \\msreport.intra\netlogon (C:\WINDOWS\SYSVOL\SYSVOL\MSREPORT.INTRA\SCRIPTS) étaient différents sur les 3 contrôleurs de domaine. Aucune erreur ne remontait dans les observateurs d’événements (journal NTFRS). La réplication NTFRS semblait arrêtée. Le service NTFRS était démarré sur les 3 contrôleurs de domaine.

COMPLEMENT D’INFORMATIONS SUR NTFRS / SYSVOL :
Le moteur de réplication NTFRS permet que le contenu des partages SYSVOL et NETLOGON soient identiques sur les différents contrôleurs du domaine Active Directory. Le moteur de réplication NTFRS s’appuie pour cela sur le moteur de réplication Active Directory et les liens de réplication de la console Sites et Services Active Directory.
Plus précisément, la réplication NTFRS est gérée par 3 objets Active Directory :
– nTDRSSubscriber : objet enfant du compte ordinateur de chaque contrôleur de domaine. Passer la console Utilisateurs et Active Directory en mode affichage « Objets Utilisateurs et Groupes comme conteneur » et en mode « Fonctionnalités avancées » pour voir cet objet.
– nTFRSReplicaSet : objet dans le conteneur SYSTEM qui contient la configuration du jeu de réplication NTFRS (appelé SET). Le chemin LDAP de cet objet est CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=msreport,DC=intra. Passer la console Utilisateurs et Ordinateurs Active Directory en mode d’affichage « Fonctionnalités avancées » pour voir ce conteneur ou lancer la console ADSIEDIT.MSC.
– nTFRSMember : objet qui référence les contrôleurs de domaine qui utilisent le SET NTFRS.  Le chemin LDAP de cet objet est CN=NOMDC,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=msreport,DC=intra. Passer la console Utilisateurs et Ordinateurs Active Directory en mode d’affichage « Fonctionnalités avancées » pour voir ce conteneur ou lancer la console ADSIEDIT.MSC.
Il est important de comprendre que :
– Le répertoire  C:\WINDOWS\SYSVOL\SYSVOL\MSREPORT.INTRA est une jonction (une sorte de lien physique) du répertoire C:\WINDOWS\SYSVOL\domain
– Le répertoire C:\WINDOWS\SYSVOL\STAGING AREAS\MSREPORT.INTRA est une junction du repertoire C:\windows\SYSVOL\staging\domain

La commande dir /aL /s C:\ permet de connaître les jonctions sur un serveur Windows.
Résultat de la commande :
Directory of C:\WINDOWS\SYSVOL\staging areas
12/03/2012  08:37 PM    <JUNCTION>     msreport.intra
0 File(s) 0 bytes
Directory of C:\WINDOWS\SYSVOL\sysvol 12/03/2012 
08:37 PM    <JUNCTION>     msreport.intra
0 File(s)  0 bytes
Le moteur de réplication NTFRS semble utiliser C:\WINDOWS\SYSVOL\domain et C:\windows\SYSVOL\staging\domain pour la réplication et non les jonctions.

ANALYSE DU PROBLEME :
Pour détermine la cause du problème, on valide l’état des 3 contrôleurs de domaine via la commande DCDIAG /V /E > c:\dcdiag.txt. Rechercher les erreurs dans le fichier de sortie. Analyser aussi les observateurs d’événements. Dans notre cas, tout était correcte.

L’étape suivante est de vérifier que les objets FRS sont bien créés. La commande NTFRSUTL DS (installer les supports Tools sur le CD d’installation de Windows Server) permet de valider que les références NTFRS sont présentes.
L’article http://support.microsoft.com/kb/312862/en-us comment recréer ses trois objets.

L’étape suivante est d’installer l’outil SONAR. Ce dernier permet de répliquer la réplication NTFRS.
Pour plus d’informations : http://www.microsoft.com/en-us/download/details.aspx?id=3745
Il existe aussi un outil appelé ULTRASOND qui permet d’effectuer cela : http://www.microsoft.com/en-us/download/details.aspx?id=3660
Hors dans notre cas, l’outil SONAR remontait « NOT A JUNCTION » au niveau de la colonne SYSVOLSHARED sur deux des trois contrôleurs de domaine.
Cela indiquait que le client avait supprimait la jonction C:\windows\SYSVOL\sysvol\msreport.intra (comme une suppression du répertoire) et avait recréé manuellement ce dossier puis recopier le contenu de ce répertoire depuis un autre contrôleur de domaine.

Pour corriger ce problème, il faut supprimer le répertoire (la fausse jonction) C:\WINDOWS\SYSVOL\SYSVOL\MSREPORT.INTRA et C:\WINDOWS\SYSVOL\STAGING AREAS\MSREPORT.INTRA et recréer la jonction avec l’outil Mklink.Exe en appliquant la procédure suivante : http://technet.microsoft.com/en-us/library/cc794939(v=ws.10).aspx

Dans notre cas taper les commandes suivantes :
cd C:\WINDOWS\SYSVOL\SYSVOL\ Mklink /j msreport.intra C:\WINDOWS\SYSVOL\domain
cd C:\WINDOWS\SYSVOL\STAGING AREAS Mklink /j msreport.intra C:\windows\SYSVOL\staging\domain

Pour télécharger l’outil MKLINK : http://downloads.netmediaeurope.de/3155/mklink-de3nle/

Si cela ne fonctionne pas, il faut alors effectuer une restauration non autoritaire de SYSVOL (clé burflags à D2) en spécifiant le serveur qui n’est pas en erreur dans SONAR. http://support.microsoft.com/kb/290762/en-us

A+

Guillaume MATHIEU
Consultant pôle Architecture & Intégration de PROSERVIA (MANPOWER GROUP SOLUTIONS)
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, Annuaire, Système, Troubleshouting, Windows 2000 Server, Windows 2003 Server, Windows Server 2008, Windows Server 2008 R2 | Laisser un commentaire

Support de cours sur Windows 7 :

Publié le 29 décembre 2012 par Guillaume Mathieu

Salut à tous

Je viens de terminer le nouveau support de cours sur Windows 7.
Au menu :
1. Configuration avancé de Windows 7:
Configuration réseau, services, disques, ajout de composant.
La base de registre Windows 7, les fichiers systèmes / démarrage.
2. Authentification Windows 7 :
Un peu de théorie (SID, TGT, TGS)
Présentation de la base SAM et de l’annuaire Active Directory.
Comment une station de travail détecte un contrôleur de domaine.
3. Partager des fichiers sous Windows 7:
Sécurisation d’un dossier avec des permissions NTFS / création de partages
Les bonnes pratiques pour sécuriser un dossier avec des ressources Active Directory
4. Internet Explorer :
Les protocoles d’authentification, les zones de sécurité, le mode compatibilité
5. Les outils d’administration de Windows 7 :
Les consoles MMC / RSAT.
PowerShell.
Prise en main à distance avec le Bureau à distance et l’assistance à distance.
6. Gestion de la configuration station de travail Windows 7 :
Les stratégies de groupe
Les scripts de login.
7. Sécuriser une station de travail avec Windows 7 :
Le pare feu
L’UAC
Les risques liés au virus et aux failles de sécurité.
APPLOCKER
8. Déploiement Windows 7 :
WAIK, WDS , MDT
9. Dépannage Windows 7 :
Méthodologie
Les outils de diagnostics.

Pour télécharger le support de cours, cliquer sur le lien ci dessous :
http://msreport.free.fr/articles/Administration_Windows_7.pdf

Bonne lecture.

A+

Guillaume MATHIEU
Consultant PROSERVIA (MANPOWERGROUP SOLUTIONS)
Le bonheur, c’est le partage.
http://msreport.free.fr

Publié dans GPO, Registre, Sécurité, Système, Troubleshouting, Virus, Windows Seven, Wsus | Un commentaire

Comment ouvrir son système d’informations aux utilisateurs externes ?

Publié le 21 septembre 2012 par Guillaume Mathieu

Bonjour

DESCRIPTION DU BESOIN :
La direction souhaite donner accès à des ressources internes à des utilisateurs externes à sa société (partenaire sur un projet, client).
Les utilisateurs externes ne doivent pas pouvoir accéder aux données confidentielles de l’entreprise (sur les serveurs de fichiers, données RH…).
Je pars du principe que l’entreprise dispose d’un annuaire Active Directory existant avec 1 domaine dans 1 forêt (pour les utilisateurs de la société) appelé MSREPORT.INTRA. Tous les serveurs d’entreprise sont sous Windows et sont membres du domaine MSREPORT.INTRA.
Les utilisateurs doivent pouvoir accéder à des serveurs de fichiers, des serveurs SharePoint (extranet) et du serveur Terminal Server / Citrix (serveurs applicatifs) ainsi qu’à des applications web.
Nous allons voir dans cet article comment restreindre les accès à des utilisateurs externes au niveau des mécanismes d’authentification. Nous ne traiterons pas des autres mécanismes : mise en place de restrictions au niveau du réseau d’entreprise, politique d’authentification forte avec archivages des connexions.

ARCHITECTURE CIBLE POSSIBLE :
Généralement, 5 solutions sont proposées :
– Scénario 1 : Créer les comptes des utilisateurs externes dans le domaine interne.
– Scénario 2 : Créer les comptes des utilisateurs externes dans autre domaine dans la même forêt.
– Scénario 3 : Créer les comptes des utilisateurs externes dans une seconde forêt et créer une relation d’approbation avec authentification sélective.
– Scénario 4 : Créer les comptes utilisateurs externes dans une base ADAM ou une base SQL et configurer l’application en questions pour s’authentifier avec cette base de compte.

Nous allons commencer par exclure le scénario 4 car il ne répond pas aux cahiers des charges. Je ne peux pas accéder à des serveurs de fichiers en m’authentifiant dans une base ADAM / SQL.

RAPPEL DES RISQUES :
Par défaut, le groupe « Utilisateurs authentifiés » a :
– Le droit de créer des fichiers et lire les fichiers sur un serveur de fichiers Windows.
– Le droit d’accéder à un site web SharePoint.
– D’ouvrir une session sur un serveur Terminal Server (mode serveur d’applications). Pour Citrix, il faut que l’administrateur est créé une publication donc c’est déjà moins risqué…

SCENARIO 1 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS LE DOMAINE INTERNE.
Tous les utilisateurs du domaine sont membres des groupes « Utilisateurs du domaine » et membre du groupe système « Utilisateurs authentifiés ».Nos utilisateurs externes ont donc accès ont donc par défaut de nombreux accès sur les serveurs de fichiers, SharePoint et serveur Terminal Server / Citrix.

Comment restreindre ces accès ?
– Créer le groupe « EXTRANET-USERS ».
– Ajouter les utilisateurs externes aux groupes « EXTRANET-USERS ».
– Configurer le compte utilisateur externe afin que ce dernier ne puisse ouvrir des sessions que sur certaines machines. Pour cela, aller dans les propriétés du compte utilisateur, dans l’onglet « Account » puis cliquer sur le bouton « Log on To » et cocher la case « The following computers ». Entrer la liste des machines sur lesquels l’utilisateur peut ouvrir sa session. L’attribut sous-jacent gère jusqu’à 1024 valeurs. Cette méthode empêche l’ouverture de session en locale mais l’utilisateur peut toujours accéder à des machines non autorisées via le réseau (accès aux partages).
Une alternative à cette méthode est de configurer le paramètre de GPO « Deny logon locally » au groupe « EXTRANET-USERS » et appliquer cette GPO sur les machines Windows réservées aux utilisateurs internes.
– Configurer le paramètre de GPO « Deny Access to this computer from the network » au groupe « EXTRANET-USERS » et appliquer cette GPO sur les machines Windows réservées aux utilisateurs internes. Ce paramètre va empêcher les utilisateurs externes d’accéder aux ressources internes.

SCENARIO 2 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS AUTRE DOMAINE DANS LA MEME FORET :
Je trouve ce scénario sans intérêt. Les forêts avec plusieurs domaines sont plus complexe à gérer.
Par défaut, Active Directory crée des relations d’approbations entre domaines d’une même forêt qui ne peuvent pas être supprimées et sur lesquels on ne peut pas activer l’authentification sélective (on en parle juste en dessous).
Un utilisateur du domaine A sera donc « Utilisateurs authentifiées » dans le domaine B et inversement. On se retrouve dans le même cas que le scénario 1 au niveau sécurité.

SCENARIO 3 : CREER LES COMPTES DES UTILISATEURS EXTERNES DANS UNE SECONDE FORET ET CREER UNE RELATION D’APPROBATION AVEC AUTHENTIFICATION SELECTIVE :
C’est clairement le scénario qui offre le meilleur niveau de sécurisation.
Le principe est de :
– Créer un domaine dans une forêt séparé.
– Créer une relation d’approbation bidirectionnel (voir monodirectionnel selon le besoin) entre ces deux forêts (relation d’approbation inter-forêts).
– Activer l’authentification sélective au niveau de la relation d’approbation.
– Configurer les accès dans les domaines. Pour donner accès à une ressource Y1 membre du domaine Y (de la forêt Y)  à un utilisateur du domaine X (de forêt X), vous devez donner le droit « Allowed to authenticate » sur le compte ordinateur de la machine Y1 à l’utilisateur du domaine X (de la forêt X). Dans le cas contraire si l’utilisateur essaie d’accéder à la ressource, il a le message d’erreur suivant « Logon Failure. The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine ».

La solution est très sécurisée par défaut mais a les inconvénients suivants :
– Vous avez deux annuaires Active Directory à gérer.
– Il faut configurer les permissions au niveau des comptes ordinateurs des serveurs de ressources (la permission « Allowed to authenticate »).
– Si vous utilisez des reverse proxy comme Forefront TMG pour publier l’Extranet, la délégation Kerberos ne fonctionne pas si le serveur Forefront TMG est dans le domaine des utilisateurs internes.
– Il faut obligatoirement activer l’authentification sélective au niveau de la relation d’approbation sinon on a les mêmes contraintes que le scénario 1 et 2.

POUR CONCLURE :
Je vous invite à partir sur le scénario 1 (domaine unique dans une forêt unique) ou sur le scanério 3 (domaine dans une forêt séparé pour les utilisateurs externes avec authentification sélective).

Pour plus d’informations :
– http://technet.microsoft.com/en-us/library/gg502594.aspx
– http://blog.msfirewall.org.uk/2008/06/using-isa-server-2006-to-protect-active.html
– http://technet.microsoft.com/en-us/library/cc995228.aspx
– http://4sysops.com/archives/how-to-use-kerberos-constrained-delegation-with-forefront-tmg/

A+

Guillaume MATHIEU
Consultant Architecture & Intégration PROSERVIA
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, Relation d'approbation, Sécurité, Windows 2003 Server, Windows Server 2008, Windows Server 2008 R2 | Marqué avec , , , , , | Laisser un commentaire

Test de SAMBA 4 RC1, une vraie alternative à Active Directory

Publié le 20 septembre 2012 par Guillaume Mathieu

Bonjour

Je viens de terminer les tests sur SAMBA 4 RC1. Le moins que l’on puisse dire, c’est que l’équipe de développement à bien travailler. Je vous invite à lire les articles suivants sur SAMBA 4 RC1.
http://wiki.samba.org/index.php/Samba4/Releases/4.0.0rc1
http://linuxfr.org/users/trictrac/journaux/samba4-disponible-en-rc

Cet article a pour but :
– De présenter la procédure de déploiement de SAMBA 4 RC1 sur un serveur Debian 6 X64 (machine virtuelle VMware Workstation 9.0).
– De valider le fait qu’un contrôleur de domaine Windows 2008 R2 peut répliquer avec l’annuaire SAMBA.
– De présenter les nouveautés de SAMBA 4 RC1 : SAMBA 4 intègre de base un serveur DNS et d’un serveur Kerberos.

1. DEPLOIEMENT DU SERVEUR SAMBA 4 :
Nous allons déployer ici une version de SAMBA 4 RC1.

1.1 PREPARATION DE LA MACHINE :
Faire une installation par défaut de Debian 6 X64.
Installer ensuite les VMware Tools. Pour cela :
apt-get install autoconf
apt-get install gcc-4.3*
apt-get install linux-headers-$(uname -r)
Dans le menu VM | Install VMware Tools.
Copier le fichier VMTools dans un répertoire de travail cp /media/cdrom/VMwareTools-8.4.2-261058.tar.gz /usr/local/src
Se positionner dans le répertoire cd /usr/local/src
Décompresser le fichier VMTools tar xzf /usr/local/src/VMwareTools-8.4.2-261058.tar.gz
Se positionner dans le répertoire cd /usr/local/src/vmware-tools-distrib/
Lancer le script ./vmware-install.pl
Répondre par défaut aux questions (touche entrée).
Les VMTools doivent s’installer et le cdrom virtuel se démonte automatiquement.
Redémarrer.
Pour plus d’informations sur l’installation des VMware Tools, voir l’article suivant :
http://eric.coquard.free.fr/Blog/files/86b7d124a6befcd0f4f1c2470c8dc04a-35.html
Changer la résolution de l’écran.
xrandr –size 1024×768
Configurer la machine avec une adresse IP fixe. Pour cela, éditer le fichier /etc/network/interfaces.
Pour plus d’informations, voir article suivant : http://www.commentcamarche.net/forum/affich-9368061-ip-statique-debian

1.2 INSTALLATION DES PREREQUIS SAMBA :
Installer les paquetages suivants :
apt-get install build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev  python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils
Ne pas installer les paquetages « krb5-config » (serveur Kerberos), « bind9 » et « bind9-host « (serveur DNS). SAMBA 4 intègre un serveur Kerberos et un serveur DNS.
Je vous invite aussi à installer VIM (éditeur de texte), NMAP (scan de port)
apt-get install vim
apt-get install nmap

1.3 CONFIGURER LE DISQUE POUR PRENDRE EN CHARGE LES PERMISSIONS ETENDUES :
Pour simplifier, les permissions étendues permettent une émulation / traduction des permissions NTFS par SAMBA sur un serveur Linux. On va modifier pour cela le fichier /etc/fstab :
cp /etc/fstab /etc/fstab.bak
vim /etc/fstab.
Il faut ajouter les paramètres user_xattr,acl  au niveau de la partition « / ». dans le cas contraire on aura une erreur à l’installation de SAMBA 4 (au make install).

Ci-dessous mon fichier /etc/fstab après modification :
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=6a9967ea-2ecc-403a-ab0c-5b54d46beb6c /   ext3  user_xattr,acl,errors=remount-ro   1  1
# swap was on /dev/sda5 during installation
UUID=dbabf6f1-8609-47b6-9a41-4719bf302cfb none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0
Pour plus d’informations, voir :
http://wiki.samba.org/index.php/Samba_4_OS_Requirements

1.4 TELECHARGEMENT DES SOURCES SAMBA 4 RC1:
J’ai rencontré pas mal de mal problème à l’installation de SAMBA 4 sur DEBIAN.
Je déconseille de passer pour l’instant par les paquetages non supportés (SID) Debian.
Nous allons effectuer une installation manuelle via les sources SAMBA 4 RC1.
Je vous invite donc à télécharger directement la version RC1 sur le site de SAMBA.
http://www.h-online.com/open/news/item/First-release-candidate-for-Samba-4-is-available-1708247.html
http://ftp.samba.org/pub/samba/samba4/

1.5 COMPILATION ET INSTALLATION DE SAMBA 4 ET CREATION DU DOMAINE :
On va maintenant appliquer la procédure suivante (étape 2) :
http://wiki.samba.org/index.php/Samba4/HOWTO
Extraire l’archive SAMBA 4 téléchargé via l’interface graphique ou avec la commande tar xzf nom-archive.gz
Ouvrir un terminal en mode administrateur et aller dans le répertoire correspondant aux sources d’installation.
Pour préparer les sources, taper la commande suivante :
./configure.developer
Pour compiler les sources SAMBA 4 RC1, taper la commande suivante :
make
Pour installer SAMBA, taper la commande suivante :
make install
L’installation de SAMBA 4 RC1 se trouve dans /usr/local/samba.

Il faut maintenant créer le domaine. On va créer le domaine Active Directory MSREPORT.INTRA. Pour cela, taper la commande suivante :
/usr/local/samba/bin/samba-tool domain provision –realm=msreport.intra –domain=MSREPORT –adminpass=’P@ssword’ –server-role=dc
L’assistant se termine en affichant le nom du SID du domaine.

1.6 CONFIGURATION DU SERVEUR DNS UTILISE PAR SAMBA :
Configurer le serveur Debian / SAMBA en tant que serveur DNS principal (il est son propre serveur).
Dans mon cas le serveur DEBIAN 6 / SAMBA 4 RC1 a pour IP 192.168.209.111.
Pour cela éditer le fichier /etc/resolv.conf :
vim /etc/resolv.conf

Modifier les valeurs des lignes « domain », « search » et « name server ». Le contenu du fichier /etc/resolv.conf est le suivant après modification :
domain msreport.intra
search msreport.intra
nameserver 192.168.209.111

1.7 DEMARRER LES SERVICES SAMBA ET VERIFIER QUE LES SERVICES SAMBA SONT DEMARRES :
Pour démarrer le serveur SAMBA RC1, taper la commande suivante :
/usr/local/samba/sbin/samba
Pour vérifier que les services SAMBA sont démarrés, taper la commande suivante :
nmap addressIPServeur
Eviter de taper « nmap localhost » car on ne voit pas le service DNS en écoute. On obtient le résultat suivant :
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
111/tcp  open  rpcbind
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
636/tcp  open  ldapssl
1024/tcp open  kdm
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
Les services ci-dessus doivent obligatoirement être démarrés.
Pour information pour arrêter les services SAMBA 4, taper la commande suivante :
Killall samba

1.8 CONFIGURATION DE KERBEROS :
J’ai pas mal galéré à cette étape. Je ne sais toujours pas quel est le fichier réellement utilisé. La procédure du WIKI SAMBA demande de créer un fichier /etc/krb.conf à partir du fichier modèle /usr/local/samba/share/setup/krb5.conf
Cette procédure ne marche pas. De plus je n’ai pas les outils KINIT et KLIST de base.
J’ai donc effectué les actions suivantes :
– Copie du fichier modèle krb.conf
cp /usr/local/samba/share/setup/krb5.conf /etc/krb.conf
– Modification du fichier krb.conf. Le contenu du fichier krb.conf est le suivant après modification.
[libdefaults]
        default_realm = MSREPORT.INTRA
        dns_lookup_realm = false
        dns_lookup_kdc = true
– J’ai ensuite installé le paquet KRB5-user pour disposer des outils KINIT et KLIST. Pour cela, taper la commande suivante :
apt-get install krb5-user
– Un assistant apparaît et me demande les éléments suivants.
Entrer le « nom du serveur de royaume ». Taper le nom complet du serveur SAMBA 4. Dans notre cas : FR092VM0001.MSREPORT.INTRA.
Entrer le « nom du serveur administratif du royaume Kerberos ». Taper le nom complet du serveur SAMBA 4. Dans notre cas : FR092VM0001.MSREPORT.INTRA.
Cela génère alors le fichier /etc/krb5.conf suivant :
[libdefaults]
        default_realm = MSREPORT.INTRA

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

Cela fonctionne une fois le paquetage Kerberos client installé et configuré. Pour tester le bon fonctionnement de Kerberos, taper la commande :
Kinit administrator@MSREPORT.INTRA
Saisir le mot de passe.
Le système doit vous renvoyer « Warning : Your password will expire in 41 days on… ».

1.9 VERIFIER LA CONFIGURATION DU SERVEUR DNS INTERNE :
Les enregistrements DNS de services (type SRV) permettent entre autres aux clients Windows de localiser les contrôleurs de domaine. Ils permettent aussi aux contrôleurs de domaine de répliquer entre eux. Dans mon cas, le nom du domaine est MSREPORT.INTRA. Taper les commandes suivantes
host -t SRV _ldap._tcp.msreport.intra
On doit obtenir la réponse suivante :
_ldap._tcp.msreport.intra has SRV record 0 100 389 fr092vm0001.msreport.intra.
_ldap._tcp.msreport.intra has SRV record 0 100 389 fr075vm0001.msreport.intra.

host -t SRV _kerberos._udp.msreport.intra
On doit obtenir la réponse suivante :
_kerberos._udp.msreport.intra has SRV record 0 100 88 fr092vm0001.msreport.intra.
_kerberos._udp.msreport.intra has SRV record 0 100 88 fr075vm0001.msreport.intra

En cas d’erreurs, forcer la mise à jour dynamique DNS :
Pour cela, taper la commande suivante :
/usr/local/samba/sbin/samba_dnsupdate
Cette commande permet au serveur SAMBA 4 RC1 de recréer les enregistrements dynamique DNS.

2 TESTS EFFECTUES :
J’ai effectué les tests suivants avec succès :
– Le domaine est créé en mode natif 2003.
– La jonction d’une machine Windows Seven X64 SP1 au domaine MSREPORT.INTRA fonctionne correctement tout comme l’authentification.
– La création d’un partage depuis le « Computer Management » de Windows 7 SP1 n’est pas possible. Par contre je peux visualiser les partages existants (NETLOGON et SYSVOL).
– Depuis une station de travail, la connexion aux liens DFS \\msreport.intra\netlogon et \\msreport.intra\sysvol  fonctionne (mappage DFS).
– L’installation d’un second contrôleur de domaine Windows 2008 R2 fonctionne via l’assistant DCPROMO.
– La réplication des objets (zone DNS, comptes utilisateurs, groupes, OU) fonctionnent.
– J’ai installé les RSAT sur la machine Windows 7 SP1 pour administrer l’annuaire SAMBA 4 (sous Debian 6). Cela fonctionne. Pour télécharger les RSAT :
http://www.microsoft.com/en-us/download/details.aspx?id=7887
– Le transfert des rôles FSMO depuis le serveur SAMBA 4 vers le contrôleur de domaine Active Directory fonctionne.

La page suivante le stade d’avancement de SAMBA 4 et les limites actuelles du produits (pas de réplication DRS-R par exemple, pas de RODC, pas de support installation d’Exchange…).
http://wiki.samba.org/index.php/Samba4/DRS_TODO_List

Pour conclure, je tiens à saluer le travail de l’équipe de développement de SAMBA 4.
Il reste cependant encore pas mal de travail. Beaucoup de fonctionnalités encore non implémentés au niveau de la console DNS par exemple…

A+
Guillaume MATHIEU
Consultant Architecture & Intégration PROSERVIA
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, Annuaire, Dns, SAMBA, Système, Windows 2000 Server, Windows 2003 Server, Windows Server 2008, Windows Server 2008 R2 | Marqué avec , , , , , | 4 commentaires