Un tech info vient rejoindre mon service info, en période d'essai pendant 2 mois, actuellement nous sommes 2 mais la seconde personne est en partance, nous avons tous les 2 tous les droits.

J'aurai aimé limiter les droits du nouvel arrivant pendant au moins les premières semaines mais en même temps il devra rapidement être opérationnel pour pouvoir me seconder. Du coup j'hésite sur la marche à suivre. Nous sommes dans un environnement majoritairement Windows avec AD et Azure AD/Office 365 synchronisé et serveur de fichier Windows, VMWare avec compte AD. Il doit pouvoir avoir accès aux serveurs et à l'AD verriez vous une solution pour ça ? Ou bien pas le choix il va falloir que je le colle Domain Admin (qui est par défaut membre du groupe Administrators donc droit sur tout le serveur de fichiers)

Sinon la seule alternative serait de ne lui faire faire que du support bureautique pendant les 2 premières semaines mais ça m'embête un peu, il n'aurait que accès au compte d'admin local des postes

Ca veux dire quoi avoir accès à l'AD et ne pas lui attribuer les droits d'admin du domaine.
S'il ne doit pas être admin du domaine, que doit-il pouvoir faire sur l'AD ?
 
Quant au serveur, son compte peut être admin local des serveurs, ou de certains, sans pour autant appartenir au groupe des admins du domaine.
 
Pour vSphere, faut lui créer un rôle avec les droits voulus. C'est assez fin. Certains rôles préexistent.

En fait je pensais à le mettre "Account operators" afin de pouvoir faire des opérations de création/modification (et delete j'ai la corbeille d'active+sauvegarde) dans un premiers temps
Cela évitera qu'il soit dans le groupe Administrators du serveur de fichier en plus
Par contre niveau Office 365/Azure AD il faudrait que je regarde s'il existe quelque chose d'équivalent, il me semble que de base on est soit user soit admin si on est membre du groupe "domain admin" donc je pense que ce groupe ne donnera pas de droits particuliers et qu il faudra le passer manuellement en tant qu'admin puis limiter ses droits

Création/modification de quoi ? Accounts Operators a beaucoup (trop, à mon sens) de droits par défaut (sur les comptes users, ordinateurs et les groupes). Selon la manière dont les DCs ont été promus le groupe se retrouve parfois même avec des droits sur les comptes ordinateurs des DCs c'est un vecteur d'exploitation bien connu.
 
Si votre structure d'OU est assez simple (ou vos objets à gérer suffisament bien organisés) pour le permettre ça serait peut être pas très compliqué de faire une petite délégation avec un groupe pour donner à ton gus juste le minimum de droits requis (reset mot de passe, ce genre de chose).

Creation/modification de compte, pouvoir joindre un poste au domaine

Ce que tu veux mettre en place, c'est une délégation AD. Mais les groupes par défaut ne conviendront pas à ton besoin (opérateurs de compte est bien trop puissant puisqu'il peut interagir avec tous les comptes).
Il faut créer des rôles personnalisés avec les permissions Adhoc.

OK merci je suis effectivement en train de faire une délégation

Je lui ai délégué les droits d'ajouter un ordinateur au domaine, et je voulais tester le droit de création/modification sur une OU
Souhaitant qu il puisse faire du RDP sur le DC plutôt que du RSAT j'ai donc modifié la DC policy afin qu il puisse s'y connecter
Par contre une fois connecté sur le DC au travers de son compte je ne peux même pas lancer la console AD User and Computer depuis sa session cela me demande une élévation de privilège

edit : j'ai l'impression que ca sera RSAT obligatoire après quelques recherches

On ne modifie jamais la Default Domain Controllers Policy, et on ne fait pas du RDP sur les DC, surtout pour déléguer des actions ! Ca n'a juste rien à voir.
 
Si tu veux qu'il gère des objets AD tu fais une délégation et tu lui fournis une machine d'admin avec les outils RSAT sur laquelle bosser.

D'ailleurs à ce sujet, j'ai fait la délégation sur son compte adm-user, s'il est connecté sur sa session user, aucun moyen de lancer en tant qu'adm-user ses outils RSAT ? Il faudrait qu il lance une VM avec sa session adm
C'est quand bien même compliqué pour le quotidien

edit : pour la default domain controller policy c'est quand même le moyen le plus simple d'empecher les utilisateurs de pouvoir joindre une machine au domaine

Commence par lister ce que tu veux lui donner comme droits, parce que là c'est pas clair du tout.

-Joindre un ordinateur au domaine
-Creer, modifier des users (non admin .. d'ailleurs à ce sujet je sais qu un account operator ne peut pas toucher aux admins, mais si je délègue une OU tout ce que s'y trouve y compris les admins peuvent être modifier/supprimer ?) dans certaines OU
-Pouvoir joindre ou modifier des groupes sur ces users (sauf les group à pouvoir de l'AD)
 
Je voudrais que toutes ces manip ne puissent être faite qu'a partir de son compte adm-user sachant qu il bossera sur sa session user quotidiennement

1) 2 façons, configure un groupe dans la DDCP et supprimer "Authenticated Users" et mettre une redirection sur "Computers", avec des ACL
2) Il faut accorder les permissions de modifier les comptes utilisateurs dans l'OU déléguée. Si ton AD est un minimum bien foutu tes comptes utilisateurs ne sont pas mélangés à tes comptes admin
3) Liste les groupes et configure son compte adm dans l'onglet "ManagedBy" (ou via l'assistant de délégation Classique).

Merci

Oui je compte faire les 3 choses par délégation (par contre pour le point 2 je ne sais pas si on peut retirer le droit de supression ensuite en affinant la stratégie par défaut proposée pour la création/modification)

Ma seule question c'est surtout : existe t il un moyen pour l'user de lancer la console RSAT en tant que adm-user depuis sa session classique ? Je ne souhaite pas lui créer un poste d'admin spécifique pour cela c'est trop lour à gérer

edit : ok trouvé, tout simplement faire Run as et se loger avec son compte adm, et donc je confirme que la délégation bloque la modif des comptes admin

Bon une fois la délégation par défaut "Ajouter/modification/suppression de comptes" sur une OU faite, j'ai 2 autorisations de créées

1-Créer/supprimer les objets Utilisateurs (sur cet Objet et tous ceux descendants) : du coup là c'est simple il suffit que je décoche "Supprimer" sur les 2 droits créés
2-Controle total sur tous les objets Utilisateurs descendants : a quoi ça correspond ? Car là dedans tout est coché

Si décoche que "Supprimer" dans 1 il peut toujours supprimer je dois éditer 2 et retirer tous les droits en suppression

La première délégation permet de créer/supprimer les objets dans l'OU désignée (et éventuellement des sous OUs qui seraient créées ensuite => cet objet et les descendants).
 
La seconde permet de gérer les objets utilisateurs déjà existants et ceux qui seraient créés par la suite (via le privilège creer/supprimer du dessus).
 
La première délégation te permettrait de créer des comptes mais pas de les gérer
La seconde délégation te permettrait de gérer les comptes existants mais pas d'en créer
 
La clé comme tu l'as relevé est bien le type d'objet auquel les permissions font référence.