A voir également:
- Compte ad qui se verrouille tout seul
- Supprimer compte instagram - Guide
- Compte facebook piraté - Guide
- Créer un compte gmail - Guide
- Créer un compte google - Guide
- Se connecter à un autre compte facebook - Guide
7 réponses
choubaka
Messages postés
39376
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
29 avril 2024
2 101
Modifié le 15 déc. 2021 à 08:18
Modifié le 15 déc. 2021 à 08:18
Bonjour
Pour tes techiciens, pas de soucis, voir avec les délégations de contrôle.
https://www.informatiweb-pro.net/admin-systeme/win-server/ws-2016-ad-ds-creer-une-delegation-de-controle.html
Pour des raisons de sécurité, tes techiciens doivent avoir deux comptes, un compte utilisateur domaine pour pouvoir accéder aux machines clientes et un compte admin (ex: Nomtulisateur.Admin) pour administrer et effectuer leurs tâches dans le domaine; Le but étant de ne pas stocker de profil administrateur sur les machines clientes.
Double authentification, on se logge sur une machine et on s'identifie en tant qu'admin sur les serveurs.
Pour le compte admin domaine, pas de soucis pour changer le mdp, à condition de garder une trace dans un endroit sûr.
Pour tes techiciens, pas de soucis, voir avec les délégations de contrôle.
https://www.informatiweb-pro.net/admin-systeme/win-server/ws-2016-ad-ds-creer-une-delegation-de-controle.html
Pour des raisons de sécurité, tes techiciens doivent avoir deux comptes, un compte utilisateur domaine pour pouvoir accéder aux machines clientes et un compte admin (ex: Nomtulisateur.Admin) pour administrer et effectuer leurs tâches dans le domaine; Le but étant de ne pas stocker de profil administrateur sur les machines clientes.
Double authentification, on se logge sur une machine et on s'identifie en tant qu'admin sur les serveurs.
Pour le compte admin domaine, pas de soucis pour changer le mdp, à condition de garder une trace dans un endroit sûr.
choubaka
Messages postés
39376
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
29 avril 2024
2 101
15 déc. 2021 à 16:00
15 déc. 2021 à 16:00
pas de problème..
En cas de besoin, revenez sur ce post.
En cas de besoin, revenez sur ce post.
kelux
Messages postés
3065
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié le 16 déc. 2021 à 15:24
Modifié le 16 déc. 2021 à 15:24
Hello,
Ce que vous cherchez à faire est un modèle de Tiering.
https://akril.net/comprendre-le-tiering-model-de-microsoft-en-francais/
En gros on découpe par profils/comptes distincts les droits d'administration liés aux :
Tier 0 : Contrôleurs de domaine
Tier 1 : Serveurs
Tier 2 : Postes de travail
Un compte d'administration ne peut cumuler les 3 profils.
On créé différents comptes pour chaque profil en gros.
Tier 0 - DC
Les droits sur les contrôleurs de domaine : groupe Builtin\administrators suffit pour la plupart des cas.
Il est possible de s'octroyer temporairement Entreprise Admin/Schema Admin/Domain Admin pour quelques taches d'administration (upgrade notamment, bouger les rôles FSMO proprement) - puis retirer le droit une fois terminé.
Ces comptes doivent avoir une restriction pour ne pas pouvoir ouvrir de session sur les autres machines autres que les DCs. On configure donc des GPOs sur les Postes et Serveurs pour interdire le login de ces comptes là.
Le droit Domain admins est à proscrire.
Tier 1 - Servers
On créé des comptes d'administration qui seront utilisés uniquement sur les serveurs.
On fait des groupes de délégation, groupe de type sécurité Domain Local.
On pourrait le nommer "DL_Admin_Serveurs_Administration".
Ensuite via une GPO dédiée aux serveurs, on utilise ce groupe pour l'ajouter aux groupes Builtin\administrators ; via la fonctionnalité "Groupes Restreints".
On peut également donner des droits de modifications des objets Ordinateurs et lier des GPOs, sur l'OU des Serveurs.
On créé un groupe DL du type "DL_Admin_Gestion_Objets-ORD_OU-Serveurs)
On utilise ensuite la délégation pour poser la délégation sur la gestion des objets Ordinateurs sur l'OU des serveurs - et pas sur le Domaine !!
On peut aussi aller plus loin et découper par type de techno : Serveurs SQL/Exchange/Citrix/NAS etc... si différentes équipes travaillent en Silo (un admin Citrix ne doit pas pouvoir etre admin des serveurs SQL par ex.)
Tier 2 - Postes de travail
Même logique, comptes dédiés pour administrer les postes de travail uniquement.
Groupe Domain Local : "DL_Admin_Postes-de-travail_Administration"
GPO sur l'OU des Postes de travail : ajout groupe restreint en tant que "Builtin\Administrators"
+ Ajout gestion des objets Ordinateurs + Link GPO sur l'OU Postes de travail.
Il y a beaucoup d'autres droits à donner pour être complet, on passe toujours pas un groupe pour le type de droits à donner, ensuite on délègue au bon endroit :
- Création d'objets GPO
- Délégation d'écriture sur le Sysvol pour les personnes qui gèrent des GPO (pour déposer les LoginScript notamment, gérer les ADMX etc...)
- Délégation des objets Users : découper les droits du type : Gestion Totale, Reset Password + Unlock (pour un support N1 par exemple)
- Délégation des objets Users pour une OU contenant que des comptes de service.
-
Ce qu'il faut retenir :
1. Stop aux droits Domain Admins
a. On ne donne jamais , mais alors jamais le droit "Domain Admins", surtout pas à des applications et encore moins à des techniciens Postes de travail ou Serveurs.
b. Si des applications tournent avec le compte administrateur du domaine (le fameux SID-500) : il faut débrayer au plus vite cela et créer des comptes de services dédiés à chaque appli.
Une application qui tourne avec des droits "Domain Admins" ou le compte Administrator SID-500 = catastrophe.
2. On ne délègue pas des droits comme montré sur le lien plus haut.
C'est à dire qu'on ne délègue pas les doits directement sur le domaine: il faut absolument ne pas faire ça !
On le fait sur les OUs qui contiennent les objets à administrer.
On ne délègue pas non plus à un utilisateur directement, mais aux groupes dédiés à chaque droit délégué - de préférence groupe de sécurité Domain Local.
3. Mot de passe compte Admin SID-500
Il est préférable (mais pas forcément facile à mettre en oeuvre) de le créer à l'aide de 4 personnes, et d'écrire la moitié du mot de passe dans une enveloppe et l'autre moitié dans une seconde enveloppe.
Les enveloppes doivent être cachetées afin de garantir l'authenticité.
Ensuite stocker ces enveloppes dans 2 endroits surs et différents (2 coffres forts ignifugés distincts par ex).
2 personnes s'occupent de saisir chacune une moitié du mot de passe (générées aléatoirement), puis le note dans leur enveloppe respective. ils ne doivent pas voir la moitié de l'autre.
Une fois le mdp setté, les 2 autres personnes saisissent chacune leur moitié respective pour valider que le login fonctionne (tenter une ouverture de session sur un contrôleur de domaine)
Les 4 personnes ne connaissent qu'une moitié du mot de passe (2 pour la première moitié et 2 pour la seconde moitié), donc impossible de le rejouer sans avoir les 2 enveloppes.
4. Poste de travail admin
Il y a la notion de PAW, qui a été énumérée avant : on dédie des postes de travail pour administrer.
L'ouverture de session est plus restreinte, config hardenée du poste etc...
C'est un sujet à tirer en parallèle/après avoir mis les premières briques d'un modèle par Tier et surtout d'avoir séparer les droits bureautiques des droits d'administration.
5. nomenclature des comptes
Autant pour les comptes Bureautiques que Admin, ou comptes de services, il ne faut surtout pas utiliser le nom ou le prénom de la personne pour le choisir, ou encore le nom de l'application.
mais plutot avec des chiffres et lettres aléatoires... du style X2765A, les chiffres ne sont pas non plus la date d'entrée de l'employé / numéro de badge ou encore sa date d'anniversaire... il ne faut aucun lien.
Lorsqu'on audite un environnement AD, la première chose pour tester si des comptes existent dans un annuaire sans accès, c'est d'aller sur linkedin, de voir que untel ou untel bosse dans la boite, et c'est parti ! Avec quelques tentatives d'authentification LDAP on devine très vite quelques logins car les nomenclatures sont souvent basées sur le nom... et on a du résultat assez rapidement en testant si les comptes existent dans l'annuaire, même si le mot de passe n'est pas le bon, on a les codes de retour que le login l'est...
-
C'est un sujet très long à aborder puis à implémenter ... il faut y aller petit à petit ;-)
Ce que vous cherchez à faire est un modèle de Tiering.
https://akril.net/comprendre-le-tiering-model-de-microsoft-en-francais/
En gros on découpe par profils/comptes distincts les droits d'administration liés aux :
Tier 0 : Contrôleurs de domaine
Tier 1 : Serveurs
Tier 2 : Postes de travail
Un compte d'administration ne peut cumuler les 3 profils.
On créé différents comptes pour chaque profil en gros.
Tier 0 - DC
Les droits sur les contrôleurs de domaine : groupe Builtin\administrators suffit pour la plupart des cas.
Il est possible de s'octroyer temporairement Entreprise Admin/Schema Admin/Domain Admin pour quelques taches d'administration (upgrade notamment, bouger les rôles FSMO proprement) - puis retirer le droit une fois terminé.
Ces comptes doivent avoir une restriction pour ne pas pouvoir ouvrir de session sur les autres machines autres que les DCs. On configure donc des GPOs sur les Postes et Serveurs pour interdire le login de ces comptes là.
Le droit Domain admins est à proscrire.
Tier 1 - Servers
On créé des comptes d'administration qui seront utilisés uniquement sur les serveurs.
On fait des groupes de délégation, groupe de type sécurité Domain Local.
On pourrait le nommer "DL_Admin_Serveurs_Administration".
Ensuite via une GPO dédiée aux serveurs, on utilise ce groupe pour l'ajouter aux groupes Builtin\administrators ; via la fonctionnalité "Groupes Restreints".
On peut également donner des droits de modifications des objets Ordinateurs et lier des GPOs, sur l'OU des Serveurs.
On créé un groupe DL du type "DL_Admin_Gestion_Objets-ORD_OU-Serveurs)
On utilise ensuite la délégation pour poser la délégation sur la gestion des objets Ordinateurs sur l'OU des serveurs - et pas sur le Domaine !!
On peut aussi aller plus loin et découper par type de techno : Serveurs SQL/Exchange/Citrix/NAS etc... si différentes équipes travaillent en Silo (un admin Citrix ne doit pas pouvoir etre admin des serveurs SQL par ex.)
Tier 2 - Postes de travail
Même logique, comptes dédiés pour administrer les postes de travail uniquement.
Groupe Domain Local : "DL_Admin_Postes-de-travail_Administration"
GPO sur l'OU des Postes de travail : ajout groupe restreint en tant que "Builtin\Administrators"
+ Ajout gestion des objets Ordinateurs + Link GPO sur l'OU Postes de travail.
Il y a beaucoup d'autres droits à donner pour être complet, on passe toujours pas un groupe pour le type de droits à donner, ensuite on délègue au bon endroit :
- Création d'objets GPO
- Délégation d'écriture sur le Sysvol pour les personnes qui gèrent des GPO (pour déposer les LoginScript notamment, gérer les ADMX etc...)
- Délégation des objets Users : découper les droits du type : Gestion Totale, Reset Password + Unlock (pour un support N1 par exemple)
- Délégation des objets Users pour une OU contenant que des comptes de service.
-
Ce qu'il faut retenir :
1. Stop aux droits Domain Admins
a. On ne donne jamais , mais alors jamais le droit "Domain Admins", surtout pas à des applications et encore moins à des techniciens Postes de travail ou Serveurs.
b. Si des applications tournent avec le compte administrateur du domaine (le fameux SID-500) : il faut débrayer au plus vite cela et créer des comptes de services dédiés à chaque appli.
Une application qui tourne avec des droits "Domain Admins" ou le compte Administrator SID-500 = catastrophe.
2. On ne délègue pas des droits comme montré sur le lien plus haut.
C'est à dire qu'on ne délègue pas les doits directement sur le domaine: il faut absolument ne pas faire ça !
On le fait sur les OUs qui contiennent les objets à administrer.
On ne délègue pas non plus à un utilisateur directement, mais aux groupes dédiés à chaque droit délégué - de préférence groupe de sécurité Domain Local.
3. Mot de passe compte Admin SID-500
Il est préférable (mais pas forcément facile à mettre en oeuvre) de le créer à l'aide de 4 personnes, et d'écrire la moitié du mot de passe dans une enveloppe et l'autre moitié dans une seconde enveloppe.
Les enveloppes doivent être cachetées afin de garantir l'authenticité.
Ensuite stocker ces enveloppes dans 2 endroits surs et différents (2 coffres forts ignifugés distincts par ex).
2 personnes s'occupent de saisir chacune une moitié du mot de passe (générées aléatoirement), puis le note dans leur enveloppe respective. ils ne doivent pas voir la moitié de l'autre.
Une fois le mdp setté, les 2 autres personnes saisissent chacune leur moitié respective pour valider que le login fonctionne (tenter une ouverture de session sur un contrôleur de domaine)
Les 4 personnes ne connaissent qu'une moitié du mot de passe (2 pour la première moitié et 2 pour la seconde moitié), donc impossible de le rejouer sans avoir les 2 enveloppes.
4. Poste de travail admin
Il y a la notion de PAW, qui a été énumérée avant : on dédie des postes de travail pour administrer.
L'ouverture de session est plus restreinte, config hardenée du poste etc...
C'est un sujet à tirer en parallèle/après avoir mis les premières briques d'un modèle par Tier et surtout d'avoir séparer les droits bureautiques des droits d'administration.
5. nomenclature des comptes
Autant pour les comptes Bureautiques que Admin, ou comptes de services, il ne faut surtout pas utiliser le nom ou le prénom de la personne pour le choisir, ou encore le nom de l'application.
mais plutot avec des chiffres et lettres aléatoires... du style X2765A, les chiffres ne sont pas non plus la date d'entrée de l'employé / numéro de badge ou encore sa date d'anniversaire... il ne faut aucun lien.
Lorsqu'on audite un environnement AD, la première chose pour tester si des comptes existent dans un annuaire sans accès, c'est d'aller sur linkedin, de voir que untel ou untel bosse dans la boite, et c'est parti ! Avec quelques tentatives d'authentification LDAP on devine très vite quelques logins car les nomenclatures sont souvent basées sur le nom... et on a du résultat assez rapidement en testant si les comptes existent dans l'annuaire, même si le mot de passe n'est pas le bon, on a les codes de retour que le login l'est...
-
C'est un sujet très long à aborder puis à implémenter ... il faut y aller petit à petit ;-)
choubaka
Messages postés
39376
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
29 avril 2024
2 101
15 déc. 2021 à 09:55
15 déc. 2021 à 09:55
Le compte administrateur de domaine est liée a plusieurs autres applications, est-il possible que les applications dysfonctionnent après le changement de mot de passe ?
c'est possible que cela pose des soucis, oui, c'est même certain.
La bonne méthode est de créer des comptes spécifiques pour les applications avec les droits suffisants (Admin domaine ou autres). Veiller aussi à ce que le mot de passe n'expire pas.
Ces comptes dits "de services" ne sont pas utilisés pour se connecter comme utilisateurs mais uniquement pour faire fonctionner les applications liées. Gros avantage, c'est que le nom des ces utilisateurs ne sont pas connus par des personnes étrangères au service. Ce qui n'est pas le cas de l'administrateur de domaine qui est lui archi-connu et donc susceptible d'attaques. (force brute par exemple).
c'est possible que cela pose des soucis, oui, c'est même certain.
La bonne méthode est de créer des comptes spécifiques pour les applications avec les droits suffisants (Admin domaine ou autres). Veiller aussi à ce que le mot de passe n'expire pas.
Ces comptes dits "de services" ne sont pas utilisés pour se connecter comme utilisateurs mais uniquement pour faire fonctionner les applications liées. Gros avantage, c'est que le nom des ces utilisateurs ne sont pas connus par des personnes étrangères au service. Ce qui n'est pas le cas de l'administrateur de domaine qui est lui archi-connu et donc susceptible d'attaques. (force brute par exemple).
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Merci pour ta réponse rapide !
Nous disposons tous de compte utilisateur de domaine qui ne sont pas administrateur. Nous nous sommes rendu compte du manque de sécurité suite à une cyberattaque. Je vais consulter ton lien qui m'as l'air très intéressant. Le compte administrateur de domaine est liée a plusieurs autres applications, est-il possible que les applications dysfonctionnent après le changement de mot de passe ?
Nous disposons tous de compte utilisateur de domaine qui ne sont pas administrateur. Nous nous sommes rendu compte du manque de sécurité suite à une cyberattaque. Je vais consulter ton lien qui m'as l'air très intéressant. Le compte administrateur de domaine est liée a plusieurs autres applications, est-il possible que les applications dysfonctionnent après le changement de mot de passe ?
