Articles

PowerShell – Galerie de codes

Très utile ce petit site de Microsoft. Ils ont eu la bonne idée de référencer des scripts PowerShell sur leur site. Il s’agit du Microsoft Script Center.

Le titre est un gros menteur car en fait il n’y a pas que du PowerShell, on trouve aussi du VBScript, SQL, VB.Net… C’est aussi trié par langage, OS, Type de script…

Pour mes besoins en PowerShell c’est parfait. Importer des users en lot (depuis un fichier Excel par exemple), lister des utilisateurs d’une OU…

Si comme moi, vus ne vous êtes jamais penché sur le PowerShell (par manque de temps ou d’envie… en l’occurrence c’est le temps pour moi), ce site vous aidera j’en suis certain.

Le site: Microsoft Script Center ou Centre de Script en français.

/0 Commentaires/par

AGDLP – La méthode préconisée par Microsoft

AGLP désigne : Account, Global group, Domain Local group, Permission.

Alors qu’est ce que ça veut dire? Cela désigne un principe quand vous créez votre arborescence Active Directory. J’entends par là quand dans la console « Utilisateurs et ordinateurs Active Directory », vous devez ajouter vos utilisateurs et vos groupes.

La méthode consiste donc à:

  • Affecter les utilisateurs (accounts) dans des Groupes globaux (Global groups)
  • Ajouter les Groupes globaux aux Groupes Locaux (Domain Local group)
  • Enfin, ces groupes sont utilisés pour attribuer des permissions NTFS (sur partages, dossiers ou fichiers).

L’image est tirée de ce site.

/0 Commentaires/par

Pourquoi il ne faut pas appeler vos domaines Active Directory en .local ou .lan

Un très bon article du blog mdmarra.com qui explique pourquoi c’est une mauvaise idée de nommer les domaines Active Directory en .local ou .lan comme il est coutume de le faire:

En substance, il dit que qu’il faut créer un sous-domaine qui soit une délégation d’un domaine parent dont vous avez la gestion. Comme: interne.mondomaine.com ou lan.mondomaine.com

Il en profite pour réfuter certaines vérités comme notamment le fait que SBS nomme ses domaines de cette façon. Ce n’est pas une raison quand on sait que SBS est fait pour des utilisateurs n’ayant pas de connaissances dans l’AD. Ou encore que certains pensent qu’ils seront protéger des attaques extérieurs s’ils nomment leur domaine en .local. C’est évidemment faux.

Il appuie en revanche ses propos en se basant sur les Best Practices de Microsoft qui existent depuis les années 2000.

Mais c’est surtout un article qu’a publié le CA/Browser en charge des recommandations en matières de certificats SSL: Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum (PDF). En gros les principaux revendeurs n’émettront plus de certificats pour les domaines fabriqués en .local ou .lan (ou autre).

Source

 

/0 Commentaires/par