none
compte admin du domaine avec acces a un seul serveur RRS feed

  • Question

  • bonjour,

    je souhaiterai cree un compte admin-rds ne pouvant se connecter que sur le serveur rds et pas sur les dc.

    J ai essaye le silo mais je dois mal mis prendre.

    Comme je fais les test sur hyper-v ca peu peut etre gene certain paramettre je sais pas.

    merci

    a+

    bon week-end

    vendredi 20 septembre 2019 15:24

Toutes les réponses

  • Bonjour Olivier,

    En gros, tu souhaites avoir un compte AD admin de la ferme RDS ?

    Juste créer un groupe de sécu AD genre "GRP_ADMIN_RDSFARM", ajouter les compte qui doivent être admin dans le groupe.

    Et ajouter le groupe dans le groupe administrateurs local de tous les serveurs de la ferme RDS. Soit à la main soit par GPO.

    Bon WE

    Cordialement


    Benoit

    • Proposé comme réponse F.ABASSI vendredi 20 septembre 2019 21:07
    vendredi 20 septembre 2019 15:54
  • Bonjour,

    Quel est l'objectif de la manip ?

    Cela pourra peut être nous donner plus d'information pour vous aiguiller

    Attention avec le principe d'administration en Silo. C'est à étudier, mais il ne faut pas se prendre la tête avec si vous êtes 2 à gérer le service informatique. Cela constituera bien plus de contraintes à gérer au quotidien que nécessaire.

    Toutefois, si cela doit vraiment être réalisé, il faut en effet créer un compte de domaine et un groupe AD qui contiendra ce membre. Vous configurer ensuite ce groupe pour être administrateur local de tous les serveurs RDS et cet utilisateur aura bien les droits d'administrateur uniquement sur ces serveurs.


    Merci de marquer comme reponses les interventions qui vous ont ete utile.

    vendredi 20 septembre 2019 16:58
  • Bonsoir

    pour commencer, le compte utilisé ne doit pas partie du groupe "admins du domaine", ni membre du groupe "administrateurs" dans AD.

    Ensuite, on peut appliquer les indications de Benoit et Matteu.

    A bientôt,


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2016(87 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate https://base.faqexchange.info

    samedi 21 septembre 2019 22:29
  • Bonjour Merci pour les réponses.mon but est de tester le Silo et mieux le comprendre. Le but est de voir comment avoir un compte administratif qui ne puisse ouvrir que le serveur rds pour le management et depuis un poste Spécifique. Et faire ça avec plusieurs comptes comme adminsrv1serveur1 adminsrv2 serveur 2, etcétéra . Et avoir un compte admin pour les dc qui s ouvre depuis seulement un poste ou groupe de poste . Merci Bon week-end
    dimanche 22 septembre 2019 11:23
  • Bonjour à tous,

    Je m'interroge également sur l'utilité d'un silo.

    Si j'ai bien compris, cela sert à créer une relation entre des ordinateurs, des comptes utilisateurs (du domaine) et des services bien définis. Seuls les comptes utilisateurs et les services déclarés peuvent se connecter sur ces ordinateurs et réciproquement  ces ordinateurs n'acceptent de connexion que de la part de ces comptes ou services, mis à part des comptes locaux ?

    Ces comptes sont ils forcément que des comptes administrateurs voire  membres du groupe "protected users" ?

    Cordialement,


    Christophe

    lundi 23 septembre 2019 12:21
  • bonsoir

    bon je n ai pas encore reussi a mettre en place un silo.

    Je ne sais pas si c est un default de comprehension ou si je suis tropc... :)

    J ai pas trouve de doc sur une procedure correct pour la creation d un silo qui permettrais a un compte admin domain de se connecter uniquement sur une machine.

    Mes tentative son vaine.

    je suis preneur de toutes infos.

    merci

    lundi 23 septembre 2019 18:24
  • Bonsoir Olivier,

    Pour les silots, il s'agit plutôt des tiers :

    Tiers 0 : compte admin du domaine, gestion des identités, pki...

    Tiers 1 : admin des serveurs

    Tiers 2 : admin des postes de travail.

    Tiers 3 : utilisateurs bureautique.

    Pour moi les admin de la ferme rds sont en tiers 1. Je précise tout ça, car un admin du domaine ne doit pas être admin d'autres serveurs que les DC.

    Autant T1 et T2 peuvent être fusionner, mais le groupe admin du domaine, lui ne devrait même pas être admin des serveurs membres et devrait être remplacé par un autre groupe d'administration.

    En suite, a toi suivant la taille de ton SI de trouver la bonne organisation entre un groupe membre du groupe "administrateurs" local de toutes mes machines membres ou par type d'environnements (ferme rds, filers, applications X...).

    Je ne sais pas si mes explications sont très claires.

    Cordialement.


    Benoit

    lundi 23 septembre 2019 18:44
  • Bonsoir Je comprends très bien ton raisonnement mais dans mon cas il n y pas de SI , je suis chez moi en lab et c est pour me donner un cadre d ordre sans avoir à faire une boulette dans mon ad avec le compte administratif . Le but est de mettre en place un silo et de comprendre le principe. Donc dans ce cas , c est d avoir un groupe rds avec mon serveur rds dedans et un compte administratif domain qui ne peux ce longueur que sur ce Serveur.ceci a des fin de tests et voir les possibilités. Exemples : puis je avoir accès après la mise en place de la stratégie silo au partage administratif d un dc. En fait voir jusqu ou ça bloque. Merci
    lundi 23 septembre 2019 20:56
  • Bonjour Olivier RB

    Différentes pistes, plus ou moins complexes à mettre en oeuvre ton été fournies.

    Si tu veux faire simple,

    • tu crées un groupes dans ton AD : appelons-le Admin RDS puisque c'est ce que tu cherches
    • Ensuite, il te reste juste à poser ce groupe dans les groupes local Administrateurs de chaque serveur RDS.

    Oui, on accordes les droits à des groupes jamais à des users. C'est trop simple et puis si on étend ton besoin à d'autres types d'usages, tu ne te vois pas faire le tour de toutes tes machines pour poser le ou les groupes qui vont bien dans le groupe admin local ? Et bien étoffe, en utilisant une GPO qui va le faire pour toi. 

    • Création d'une GPO qui va utiliser des groupes restreints (tu trouveras sur le net des tonnes d'articles qui parlent de comment mettre en oeuvre une GPO groupe restreint). 
    • Tu lies ta GPO à tes machines

    Le plus facile : tu crées dans ton AD une sous OU ou tu mets tes serveurs RDS et tu lies ta GPO à cette OU. Ainsi toute nouvelle machine placée dans cette OU se prendra cette GPO by design.

    Moins bien : tu crées un groupes de sécurité que tu peuples avec des comptes machines et tu lies ce groupe à ta GPO. Ca marche tout autant, mais c'est beaucoup moins pratique. Imagine ce que cela peut donner dans un grand parc (qui bouge très souvent). Les équipes d'admin se rappeleront-t-elles dans 1 an que tout nouvelle machine arrivant répondant à tel ou tel critère doit alimenté tel ou tel groupe de l'AD ? Non ! La maintenabilité de cette solution est bien moindre que la première. 

    Tu peux également lier ta GPO avec un filtre WMI (par exemple une convention de nommage) mais sera-ce toujours respecté demain et dans un an ? On peut en douter, il y a toujours de l'humain la-dedans.

    Enfin tu veux contruire -dans un lab ou pour dans un environnement plus important - un vrai silotage, oui un truc qui respecte le principe du moindre privilège. OK, il y a plein d'articles sur le sujet, à lire, à comprendre à intéger afin de se faire une philosophie.

    En fait, il me semble voir ce qui te bloque au vue des questions que tu te poses. Ex. "puis je avoir accès après la mise en place de la stratégie silo au partage administratif d un dc."

    Réfléchissons  ensemble :

    Qui peut avoir accès à un partage administratif (c$, d$, ..) ?

    Seuls les membres du groupe Administrateurs local (ou équivalement sur un DC). T'es pas membre tu n'accèdes pas.

    QUi peut ouvrir une session RDP sur un serveur (ou un DC) ?

    Par défaut, si les connexions RDP sont autorisées mais qu'il n'y a aucun groupe de renseigné, c'est encore une fois le groupe Administrateur local.

    Je parle de connexion RDP pour faire de l'administration, par pour un serveur RDS ou dans ce cas, les groupes devant utiliser le RDS sont ajoutés en accès  pour les sessions Remote Desktop.

    Nota : pas besoin d'accéder en RDP à une machine pour l'administrer. Le remote Admin et le remote shell, sont des solutions bien plus pratiques au quotidien.

    Je veux aller plus loin dans le silotage avec implémentattions de groupes Tiers X qui ne peuvent se connecter que sur certains serveurs ?

    Ca se fait, mais ça se pose par écrit avant implémentation (ca permet de voir à tête reposée ce qu'on a oublié d'implémenter dans notre raisonnement).

    J'ai entendu parler d'élévation de privilèges, de déplacement latéral de Pass-The-Hash (PtH), de pass-The-Ticket (PtT), comment puis-je limiter ce risque ?

    On monte progressivement en complexité mais c'est ainsi qu'il faut penser. Avant tout les anglo-saxons parlent de "mitigation", ce qu'on peut traduire en français par réduction, pas par suppression. Le risque 0 n'existe pas.

    Le mot clé:PAW

    PAW pour Privileged Access Workstation (poste à accès priviligié). Mais kesako ? Un poste d'administration tout simplement. Et bien sur ces types de poste, seuls les comptes membre d'un groupe Tiers particulier peuvent ouvrir une sesison, et pour administrer (RDP, remote shell, remote Admin, web, ...) que les machines du même tiers. Naturellement, les comptes du (ou  les) dit groupes ne peuvent également pas de connecter à de simples postes de travail (sinon ça ne sert strictement à rien sauf à rendre ton infra plus complexe).

    Tu trouveras facilement des tonnes de docs sur le sujet (y compris chez microsoft et en français) sur le Net.

    pour ton "lab", commence simple. On va dire que ton lab est consitué de machines virtuelles.

    - 1 VM DC/DNS (oui, dans un lab, tu n'as mis qu'un DC).

    - quelques serveurs membres

    - 1 poste de travail d'administration

    - crées dans ton AD quelques comptes utilisateurs ainsi que quelques groupes d'administration, et alimente tes groupes.

    puis, suis la démarche décrite ci-dessus, en partant du plus simple et étoffe petit à petit. Pas de crainte à avoir su mets en place un truc qui te coupe l'herbe sous le pied, tu as toujours un compte "domain Admin" pour te rattraper.

    Notes bien que tu t'attaques là à un vaste sujet, qui peut s'avérer complexe à comprendre, à implémenter et à utiliser au quotidien si pas bien réfléchi en amont. Et si ce n'est pas bien compris, pas les équipes d'admin notamment, ça va vite dériver. Et là, rien de pire que de se croire en sécurité alors qu'on a de gros trous dans la raquette parce que des c... n'ont pas suivi les règles. Alors derriere, il faut penser à mettre en place des moyens de contrôle continus (SIEM, UEBA, ...) ou ponctuels (Audit) et de la "remediation" (assainissement ou correction en bon français) et du "Compliance Management" (Gestion de conformité en bon français).

    Penses à cette jolie roue que l'on voit souvent (Design - build - Audit - correct) ou équivalent. Et bien c'est dans ce même sens que tu dois aller. tu conçois quelque chose (et donc le documente), construction, audit, corrections et amélioration et c'est reparti pour un tour.

    Olivier

    mardi 24 septembre 2019 05:21
  • Bonjour oliv-thefrog’ Je pense que tu n as pas bien lu mon post précédent. Je ne veux pas faire du Classic, je suis en lab donc je veux faire du test en silo. Vaste sujet complexe mais si on n essaye pas un peu quitte à se planter , merci la virtualisation 😂. Ça existe ,donc j essaye de mettre en œuvre Mais merci quand même pour tes explications. Bonne journée
    mardi 24 septembre 2019 06:03
  • Bonjour Olivier Rb,

    Pour information, je suis tombé sur un post qui aborde de façon assez synthétique la mise en place des Protected Group, des stratégies d'authentification et des silos.

    C'est un post d'un tchèque https://translate.google.com/translate?u=https://blogs.technet.microsoft.com/technetczsk/2015/10/13/active-directory-2012-r2-authentication-policies-and-silos/&langpair=cs%7Cfr&hl=fr&ie=UTF8.

    Tout est configuré en powershell, alors qu'il existe une interface GUI pour gérer les "Authentification Policy Silos" dans le "centre d'administration Active Directory".

    Ce que je n'arrive pas à comprendre c'est comment joindre une groupe d'utilisateur ou d'ordinateur dans le silo et que cela vive de façon  dynamique. On ne peut sélectionner que des comptes et non des groupes.

    Get-ADGroupMember -Identity 'Admins du domaine' | ForEach-Object {Set-ADAccountAuthenticationPolicySilo –identity $ _. DistinguishedName –AuthenticationPolicySilo Restricted_Logon_for_Admin}

    Cette commande ajoute en un instant T de façon unitaire les membres du groupe "Admins du domaine" dans le silo. Si on ajoute un utilisateur dans ce groupe, il faut penser à  relancer la commande pour le lier au silo.

    Pour ma part ce que je cherche c'est à définir un groupe administrateur de l'AD qui seraient les seuls à se connecter sur les ordinateurs du Tier 0 ou Silo AD constutué des contrôleurs de domaine et les postes d'adminstrateurs dédiés au Tier0. Ces utilisateurs Adminstrateur AD ne pourraient pas se connecter sur les autres machines.

    Et faire de même pour les ordinateurs et administrateurs du Tier 1

    Ce que tu cherches Olivier, c'est  bien de créer un ou des silos de serveurs RDS et d'administrateurs qui lieraient ces serveurs et administrateurs :

       - siloRDS_A : serveurs RDS1  et RDS2, administrateurs : admRDS-paul et admRDS-jacques

       - siloRDS_B : serveurs RDS3, RDS4 et RDS5, administrateurs : admRDS-paul et admRDS-marie

    admRDS-paul peut se connecter et administrer les 5 serveurs RDSx

    admRDS-jacques peut se connecter seulement en tant qu'administrateur sur RDS1 et RDS2. Il ne peut se connecter sur aucun autre ordinateur (RDS3, RDS4 RDS5, Contrôleur de domaine, poste de travail)

    admRDS-marie peut se connecter exclusivement  sur RDS3, RDS4 et RDS5

    Cordialement

    Christophe


    mardi 24 septembre 2019 08:26
  • REbonjour

    Autres liens :

    https://www.petri.com/how-to-create-a-windows-server-2012-r2-authentication-policy

    https://www.petri.com/restrict-privileged-accounts-with-authentication-silos-in-windows-server-2012-r2

    Cordialement

    Christophe

    mardi 24 septembre 2019 08:55
  • bonjour

    merci pour la doc j avais certain de ces lien.

    je crois que c est pas gagne :)

    un lien pour toi

    https://www.sstic.org/2017/presentation/administration_en_silo/

    a+

    mardi 24 septembre 2019 15:43