Bonjour
 
J'hérite d'une situation inédite pour moi :  
Sur un même site géographique, 2 entités à l'origine distinctes cohabitent.
Chaque entité a son DC, son domaine, ses périphériques... et partagent un switch. Chacun est sur son LAN distinct, et il n'y a même pas un VLAN pour séparer proprement.
Un peu de routage pour gérer la possibilité des PC d'une entité à accéder à des données de l'autre entité.
 
L'entité "entite_A", de domaine AD entite_a.lan, a son serveur RDS, sa passerelle RDS
L'entité "entite_B", de domaine AD entite_b.lan, n'a rien de tout ça, et trouverait ça bien sympa d'avoir la même chose.
 
N'ayant qu'une seule ligne internet pour les deux entités, et qu'une seule IP publique, je vais devoir utiliser la même passerelle RDS.
Sachant que les deux entités n'ont rien à se cacher
 
Ma question :  
Dois-je faire dialoguer mes 2 forets ensemble (et comment ), et permettre à mes utilisateurs "entite_B" de s'authentifier sur la passerelle RDS avec leurs identifiants entite_B\userx, ou
M'est il possible de rendre accessible le serveur RDS "entite_B" depuis ma passerelle "entité_A" sans que les domaines ne se connaissent, monnayant 2 authentifications, une pour la passerelle, une pour le serveurs RDS entité_B ?
 
Vos avis ?

Tu fais une relation d'approbation entre les forêts et ça devrait le faire

En suivant ce tuto par exemple ?
http://pbarth67.free.fr/?q=node/43

De façon corolaire, et avant d'attaquer je préfère vérifier : Il y a quelques services communs aux deux entités qui sont sur entité_A, et j'ai eu besoin que l'entité B puisse résoudre des noms en "entite_a.lan", alors j'ai mis un DNS secondaire du domaine entite_A sur le serveur DNS de entite_B. Ca change quelque chose pour la relation d'approbation, ou je la laisse ma zone secondaire ?
Edit : Je vois dans la procédure qu'il est demandé de créer une zone de stub. Je peux laisser ma DNS secondaire à la place ?

par exemple, même s'il y a des trucs inutiles genre la zone dns inverse mais bon. Après soit un trust externe soit forêt, pour toi ça change pas gd chose vu que c'est 2 forêts mono domaines
 
j'ai pas vu de zone de stub moi dans le truc.
 
Tt ce qu'il faut c'est que les machines de domaine 1 puissent résoudre le nom dns des machines de domaines 2 et inversement

Excuse, je regardais plusieurs tuto en même temps, c'est sur un autre où ils faisaient créer une zone de stub.
Ok, ben feu alors !  
Merci.

Ralalalala les admins qui ont l'habitude du tout virtualisé, quand ils repassent en physique, c'est la cata
 
Plus sérieusement, pour simplifier 1 forêt = 1 vlan, t'as 2 forêts, donc t'as l'équivalent de 2 vlan, a partir de là, n'importe quel tuto de trust en virtuel fonctionne.
Et la config de tes 2 entités est plutôt propre a comprendre , mettre en oeuvre et maintenir, juste que t'as pas l'habitude d'y avoir a faire. PS : le switch joue le rôle de passerelle, tu colle de intelligence dedans (genre un routeur ? ) et tu les fait dialoguer tes deux forêts, genre facilement <_<

Comme je le disais, ça dialogue sans problème, si on parle de routage.
Mon problème est sur l'authentification entre forêts qui s'ignorent.
 
Je vais suivre les conseils de Je@nb, et on va voir comment ça se fini

Après a voir les impacts et le nb d'user mais ca serait pas deconnant de passer en mono foret mono domaine

Ca reste deux entités juridiquement distinctes, je pense que les dirigeants aiment l'idée que les choses soient... séparées, aussi relatif que les choses puissent être en vérité...

Ouais mais si tu commences à faire des relations d'approbations, ok la forêt reste la frontière de sécurité mais tu établis des connexions.
Tu peux faire un trust sélectif pour diminuer la portée du trust à quelques entités, à voir selon le niveau de sécu que tu veux.

Non non, je ne veux pas restreindre quoique ce soit.
Ca reste deux forets distinctes pour des raisons non-informatiques, mais pour le reste, plus je peux "faire comme si" j'avais deux UO au lieu de 2 forets, je prends

Tout s'est passé presque trop bien    
Il me reste un détail à régler : Le serveur de licence RDS.
J'en ai qu'un à ce jour, sur domaineA.lan
J'aimerais bien que mon serveur RDS sur domaineB.lan puisse se faire attribuer des cals par le même serveur de licence (qui est sur domaineA.lan).
 
Vous savez comment faire ça
 
Pour ce reste, ça marche au poil  

Tu aurais beaucoup moins de problèmes et de taf si tu fusionnais tout en un seul domaine/forêt puis en créant deux OU ensuite...

sio tu as un two-way trust alors suffit de configurer ton serveur rds du domaineB pour utiliser le serveur de licences du domainA

Oui, et j'aimerais bien gagner au loto aussi   mais on a pas toujours ce qu'on veut    
En gros c'est une contrainte que j'ai, je fais avec.

Humm, en retournant sur le serveur faire une capture d'écran, j'ai vu un pavé "fournir les informations d'identification du serveur de licence".
Devine quoi, en les saisissant, ça fonctionne...    

voilà c'est ce que je disais

Bon, ben le sujet est clos on dirait

Ouais désolé, journée de merde, donc pas très constructif sur ce coup là

Pas de soucis    

Petit soucis corollaire :  
Tout fonctionne bien, mes deux entité A et B ont bien accès à la passerelle avec leurs propres applis sans voir celles de l'autre entité, ca roule.
Par contre : Pour ce qui est de l'accès bureau à distance, je ne parviens pas à à faire la même chose. Je m'explique :  
 
Sur la page WebTS, chaque utilisateur de chaque entité se retrouve avec ses propres appli mais avec 2 raccourcis "Bureau à distance". Ça encore, c'est pas trop grave, j'ai qu'à expliquer à chaque utilisateur si il doit choisir le premier ou le deuxieme (meme si j'aimerais bien avoir la main pour renommer "bureau à distance" comme on peut le faire pour les applis).
Le problème, c'est pour les "connexions remoteApp et bureau à distance" configurés sur les postes Windows7. Là, je n'ai qu'un raccourcis bureau à distance, pas deux comme sur la pageWebTS, et là je suis marron.
 
Vous savez résoudre ça

un .cmd qui pointe vers mstsc.exe avec une ligne de commande bien propre ?
 

 
Edit : ou alors tu fait un raccourci et dans le champ "cible" du raccourci tu va renseigner les champs /v etc ...

Lol oui remarque, je cherchais dans les options et configurations "propres" du serveur bureau à distance, mais ça semble en effet un moyen de contournement simple et efficace, et je désactive la mise en place de l'icone "bureau à distance" made in MS.

C'est la méthode barbare, mais elle a le mérite d'être idiotproof <_<

   
Ca me surprends que ce "bug" n'ait pas été relevé et corrigé.
Il ne doit pas y avoir chez moi que l'accès bureau à distance intéresse et qu'il y a plusieurs serveurs TS différents. Et ca de base, tu peux pas gérer  

 
Euh, c'est pas un bug, c'est juste que le bureau a distance (MS Terminal Server) possède un client propre (MS Terminal Server Client > MSTSC) qui est en .exe et non pas en service.
L'icône sur le bureau n'est qu'une icône de raccourci avec une clé spécifique. Un peu comme l'icône "GodMode"
L'icone en question c'est ni plus, ni moins qu'un dossier mstsc.{clébarbarequejeconnaismêmepas}
Essaye ce "trick" :
Créer un dossier sur le bureau et renome le GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Ca fait juste appel a des fonctions de l'explorateur. Mais sinon tu peut parfaitement pointer un raccourci vers l'exe qui nous interesse. (la en l'occurrence c'est mstsc.exe)
Dans les autres features intéressantes de windows 7 et + t'a le "reliability" : dans l'onglet de recherche du menu démarrer cherche "realibility", ça te sortira l'observateur d'evenements, mais en mode graph.
 
En fait tout les raccourcis qui peuvent être utilisés par le système se trouvent plus ou moins dans le registre en HKEY_CLASSES_ROOT\CLSID\
Si tu veux vraiment une manière élégante de faire les raccourcis : tu peu en faire un par "connexions remoteApp et bureau à distance", je te fait les screens qui vont bien quand je change d'OS (j'ai pas le bon la)

Tu peux déployer un raccourci plus proprement par GPP je pense.

Bon, j'ai trouvée les ID des shells mais j'arrive pas a le mettre en oeuvre pour MSTSC x_x
Edit : Bon j'arrive a remplacer le shell sur une machine distante via la connection RDP pour ne lancer que l'applicatif, mais j'arrive pas a "sheller" l'applicatif directement via MSTSC avec des params en base de registre, faudra te contenter du raccourci vers mstsc.exe et modifier la ligne cible pour le moment, t'en fait deux (1 par serveur que tu veux joindre), tu les bloque et tu les déploie par GPP, ça ira grandement (si je trouve via édition de base de registre et GPO, je te dit)

Oui c'est certains. Je me demande par contre si je me suis bien fait comprendre sur ce qui me surprend dans le fait que ça ne soit pas géré, ça coutait rien de mettre deux icones pour les deux bureaux dans les remoteApp plutôt que de n'en mettre qu'une, alors que dans le WebTS il y en a bien deux.
Deuxième chose, je ne comprend pas pourquoi je ne peux pas choisir quels groupes se voient publier l'accéder au bureau à distance alors que pour les Apps on peut choisir les groupes.
Je ferai des captures d'écran lundi, ça sera sûrement plus clair.
 
Pour la solution en elle même, elle m'a été soufflée plus haut, publier des mstsc avec les paramètres qui m'intéressent ou publier des bat qui contiennent mstsc + les paramètres qui vont bien .

Bon, j'ai finalement suivi les préconisations de féniants : J'ai enlevé les "publier un accès au bureau à distance", et j'ai mis un raccourcis vers "mstsc /v ....".
Mes deux problèmes réglés d'un coup (chaque site a accès à son serveur uniquement en WebTS, et sur leurs PC portable ils ont un lien vers leur serveur et non vers le serveur du voisin).