dcdiag – VerifyEnterpriseReferences – msDFSR-ComputerReferenceBL – Q312862

En préparant un plugin nagios sur la santé AD, dcdiag /e /c a eu la bonne idée de remonter cette alerte:

Starting test: VerifyEnterpriseReferences

The following problems were found while verifying various important DN

references. Note, that these problems can be reported because of

latency in replication. So follow up to resolve the following

problems, only if the same problem is reported on all DCs for a given

domain or if the problem persists after replication has had

reasonable time to replicate changes. 

 [1] Problem: Missing Expected Value

Base Object: CN=myDC,OU=Domain Controllers,DC=mydomain,DC=net

Base Object Description: "DC Account Object"

Value Object Attribute Name: msDFSR-ComputerReferenceBL

Value Object Description: "SYSVOL FRS Member Object"

Recommended Action: See Knowledge Base Article: Q312862

 

L’article Q312862 n’est plus vraiment d’actualité, mais le problème sous-jacent est bien réel.

Depuis Windows 2008, la réplication AD est censée se faire via DFS-R et non plus FRS. Cependant, cela implique de n’avoir plus que des DC > Windows Server 2003.

Donc si vos DC sont à jours, il faut utiliser dfsrmig dont les principales commandes sont:

Vérifier l’état global:

PS C:\users\mchateau\Desktop> dfsrmig /GetGlobalState

Current DFSR global state: 'Start'

Succeeded.

Les différents états possibles sont:

0 'Start'
1 'Prepared'
2 'Redirected'
3 'Eliminated'

==>Si vous êtes déjà en DFS-R, l’état est Eliminated.

 

Vérifier l’état de la migration:

PS C:\users\mchateau\Desktop> dfsrmig /GetMigrationState

All domain controllers have migrated successfully to the Global state ('Start').
Migration has reached a consistent state on all domain controllers.
Succeeded.

 

Passer à l’état Prepared:

PS C:\users\mchateau\Desktop> dfsrmig /SetGlobalState 1

Current DFSR global state: 'Start'

New DFSR global state: 'Prepared'

Migration will proceed to 'Prepared' state. DFSR service will copy the contents of SYSVOL to SYSVOL_DFSR folder.
If any domain controller is unable to start migration, try manual polling.
Or run with option /CreateGlobalObjects.
Migration can start anytime between 15 minutes to 1 hour.
Succeeded.

 

Vérifier l’état (en cours):

PS C:\users\mchateau\Desktop> dfsrmig /GetMigrationState

The following domain controllers have not reached Global state ('Prepared'):

Domain Controller (Local Migration State) - DC Type
===================================================

myDC01 ('Start') - Writable DC
myDC02 ('Start') - Writable DC
myDC03 ('Start') - Primary DC
myDC04 ('Start') - Writable DC

Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.
PS C:\users\mchateau\Desktop>

 

Il ne reste plus qu’à faire les 2 états suivants tour à tour:

dfsrmig /SetGlobalState 2
dfsrmig /SetGlobalState 3

 

Au final:

PS C:\users\mchateau\Desktop> dfsrmig /GetMigrationState
All domain controllers have migrated successfully to the Global state ('Eliminated').
Migration has reached a consistent state on all domain controllers.
Succeeded.

Internet Information Services (IIS) Manager. Bad Data. (Exception from HRESULT: 0x80090005)

Symptômes:

Lorsque vous accédez à la console IIS ou aux pools d’applications, vous avez l’erreur suivante:

Bad Data. (Exception from HRESULT: 0x80090005)

Causes:

Vous avez copié le fichier de configuration de IIS d’une machine à l’autre (C:\Windows\System32\inetsrv\config\applicationHost.config)

Ce dernier contient des comptes Windows pour certains pools d’applications. Le mot de passe est encrypté en utilisant une clé locale à la machine, l’autre serveur n’arrive donc pas à les décrypter.

Corriger le mot de passe à la main depuis la console IIS ne résous pas le problème.

Résolution:

2 possibilités:

  • Faire un retour arrière sur le serveur où la configuration a été copiée. Par défaut IIS garde une copie des 10 derniers fichiers de configuration (C:\inetpub\history)
  • Utiliser la méthode supportée pour copier la configuration.

Exporter la configuration:

aspnet_regiis -px "iisConfigurationKey" "C:\iisConfigurationKey.xml" -pri 
aspnet_regiis -px "iisWasKey" "c:\iisWasKey.xml" –pri

Importer sur la cible:

aspnet_regiis -pi "iisConfigurationKey" "C:\iisConfigurationKey.xml" 
aspnet_regiis -pi "iisWasKey" "C:\iisWasKey.xml"

GPMC : 0x80070005 – access denied – E_Accessdenied

En voulant modifier une GPO chez un client, j’ai eu ce message d’erreur GPMC, et la GPO n’est effectivement pas modifiée:

En utilisant Process Monitor, de Sysinternals, l’accès au fichier registry.pol est refusé alors que mon compte est admin du domaine:


Suite à un incident et une restauration autoritaire, les fichiers ont en fait l’attribut lecture seule:

Après avoir décocher l’attribut lecture seule, la modification des GPO fonctionnent de nouveau 🙂

Ferme RDP avec broker: comment accéder à un serveur spécifique ?

Hypothèses

  • Vous avez une ferme RDP avec par exemple 2 serveurs RDP,
  • Vous avez le broker en place, donc les utilisateurs sont redirigés vers leur connexion actuelle (affinité),
  • You avez restreint à une session par utilisateur.

Problème

Quand vous essayez de joindre un serveur RDP spécifique de la ferme (pour faire de l’admin dessus ou aider un utilisateur qui est dessus), vous êtes refusé:

La connexion ne peut pas être établie car l’ordinateur distant qui a été joint n’est pas celui que vous avez spécifié. 
Cela peut être dû à une entrée obsolète du cache DNS. Essayez d’utiliser l’adresse IP de l’ordinateur à la place du nom.

 

Idem en essayant par l’adresse IP comme suggéré:

Cet ordinateur ne peut pas se connecter à l’ordinateur distant.

L’ordinateur distant auquel vous essayez de vous connecter vous redirige vers l’ordinateur distant. 
La Connexion Bureau à distance ne peut pas vérifier que les deux ordinateurs distants appartiennent à la même batterie de serveurs. 
Ceci peut se produire si un autre ordinateur du réseau porte le même nom que celui auquel vous tentez de vous connecter.

 

Solution

Il suffit d’utiliser le fameux /admin du client RDP pour bypasser les règles !

 

 

Windows 2008 failover cluster: Failed to prepare storage for testing on node <> status 87

En voulant monter un failover cluster Windows Server 2008 R2:

 

 

 

 

 

 

 

Pour corriger le problème, il faut assigner temporairement une lettre de lecteur à la partition bitlocker (FAT32 / 2Go) (créée automatiquement par Windows):

 

 

 

et voilà 🙂

Sécuriser son Windows dans le cloud (Dedibox/Amazon…)

Suite  à mon retour vers Dedibox, et le fait que j’y installe du Windows, je me suis demandé ce que je pouvais faire pour la sécuriser.

Voici les pistes envisagées:

  • Pas de port TCP accessible directement. Passer donc par exemple avec LogMeIn, au moins pendant la configuration. L’accès idrac n’est pas assez fluide et simple d’accès.
  • Renommer le compte Administrateur via GPedit
  • Interdire l’affichage du dernier compte authentifié via GPedit.
  • Ajouter un disclaimer, toujours via GPedit. Cela n’arrêtera pas un pirate motivé, mais peu suffire à bloquer certains logiciels de brute force RDP.
  • Autoriser RDP mais:
    • Sur un port TCP non standard. Procédure Microsoft : http://support.microsoft.com/kb/306759/en-us/
    • Utiliser le firewall Windows pour autoriser l’accès uniquement depuis certaines IP fixes. Pour y accéder depuis ailleurs, d’abord se connecter en LogMeIn pour modifier la règle firewall.
    • Autoriser uniquement les clients permettant une authentification réseau.
  • Scanner régulièrement les adresses IP depuis l’extérieur avec nmap pour vérifier ce qui est visible.
  • Appliquer les mises à jour Windows dès leur sortie.

Dedibox: Nat de VM Hyper-V

Suite au retour sur Dedibox, j’ai décidé d’utiliser Hyper-V plutôt que VMware pour la virtualisation. Les adresses IP publiques sont facturées chez Online.net, et d’autre part je ne veux pas que certaines VM soient exposées sur Intrenet (DC, Exchange…).

Par défaut, Hyper-V ne permet pas de faire du Nat, et donc cacher tout se beau monde tout en leur donnant accès à Internet.

Voici les grandes étapes:

  • Installer le rôle Network Policy and Access Services
  • Créer un réseau interne dans Hyper-V
  • Assigner une adresse IP fixe (ex 192.168.1.1) sur la carte réseau du réseau ainsi crée (carte virtuelle Hyper-V)
  • Configurer Routing and Remote Access pour faire du NAT
  • Configurer les VM afin d’utiliser le réseau virtuel Hyper-V et de passer en DHCP ou IP fixe suivant vos souhaits.

Ajouter le rôle

Configurer le NAT

Windows Server 2008 R2 – Administration avancée est sorti!

La nouvelle version du livre pour Windows Server 2008 R2 est disponible chez ENI, toujours à la fois en livre papier et numérique

Il s’applique toujours à la version précédente, car on a spécifié quand c’est R2 seulement. Il inclut également un nouveau chapitre dédié à la haute disponibilité

WDS/MDT: enlever F12

Par défaut, pour démarrer depuis le réseau via WDS, il faut:

  • Indiquer pendant le bios de démarrer sur le réseau (F12 en général)
  • Une fois le bail DHCP obtenu, il faut de nouveau et rapidement presser F12 pour vraiment démarrer sur le réseau

Cette deuxième confirmation est une sécurité. Si l’ordre de boot positionne le réseau avant le disque dur, les machines essaieront tout le temps de démarrer via le réseau avant le disque dur. En général, on démarre sur le réseau uniquement pour installer le système d’exploitation, et ensuite tout le temps depuis le disque dur.

Moyennant d’avoir les bios correctement configurés, le deuxième F12 est en trop. Depuis WDS (2003 et 2008), il suffit de remplacer pxeboot.com par pxeboot.n12 pour supprimer le deuxième F12:

Pour rattraper un historique sur un parc existant, Dell et HP offre des outils centralisés pour paramétrer le bios des machines à distance (génération d’un exécutable à télé-distribuer en général):