Après mon premier article sur l’utilisation d’UCP avec un certificat, nous allons voir comment faire de même avec DTR.

Les prérequis sont simples, avoir un ordinateur pour générer le certificats, un serveur pour DTR qui est déjà joint comme simple nœud à l’UCP, le certificat root de la PKI et un peu de temps

Pour commencer, depuis un ordinateur Windows qui est dans le même domaine que la CA, générez un nouveau certificat de type Web Server. Ajoutez lui les DNS correspondant aux futurs URL disponibles:

Cochez bien la case pour pouvoir exporter la clé privée:

Exportez ensuite le certificat avec sa clé privée:

Pour transformer les certificats en PEM et séparer la clé privée de la clé publique, vous aurez besoin de openssl. Exécutez les commandes suivants:

C:\OpenSSL-Win32\bin\openssl.exe pkcs12 -in "FLOAPP-DTR01.pfx" -nocerts -out "key.pem" –nodes

C:\OpenSSL-Win32\bin\openssl.exe pkcs12 -in "FLOAPP-DTR01.pfx" -nokeys -out "cert.pem"

Et pour supprimer la passphrase du certificat qui contient la clé privée:

C:\OpenSSL-Win32\bin\openssl.exe rsa -in "key.pem" -out "key.pem"

Allez ensuite sur votre site qui héberge DTR, https://votreip et allez dans Settings. Modifiez la partie Domain avec votre nouveau nom DNS, puis dans la partie TLS certificate, copiez la clé publique de votre certificat (cert.pem), ensuite dans TLS private key, la clé privée de votre certificat (key.pem) et enfin, dans TLS CA, la clé de votre CA, puis sauvegardez:

En allant sur https://votreurl vous devriez avoir votre nouveau certificat:

Il faut maintenant enregistrer votre serveur DTR dans l’UCP. Allez dans l’UCP, puis dans Settings > DTR. Renseignez l’URL vers votre DTR. Le certificat n’est pas nécessaire car l’UCP trust déjà le certificat:

Il faut maintenant truster la CA root que l’UCP a créé. Sur le serveur UCP, utilisez la commande suivante pour récupérer le certificat:

sudo docker run --rm --name ucp -v /var/run/docker.sock:/var/run/docker.sock docker/ucp dump-certs --cluster –ca

Copiez ce certificat dans un fichier nommé ucp-cluster-ca.pem. Copiez le résultat dans le DTR, dans Settings > Domain > Auth Bypass TLS Root CA:

Il faut maintenant copier le certificat root qui se trouve dans l’interface DTR, Settings > Domain > TLS CA dans /etc/docker/certs.d/dtr.florentappointaire.cloud/ca.crt. Utilisez les commandes suivantes pour créer le chemin et remplir le fichier avec le certificat:

mkdir -p /etc/docker/certs.d/dtr.florentappointaire.cloud/
vi /etc/docker/certs.d/dtr.florentappointaire.cloud/ca.crt

Vous devez effectuer ceci sur chaque nœud de l’UCP. Je vais maintenant pousser une image docker, en l’occurrence celle-ci https://github.com/Flodu31/Floapp-Cloud , sur mon DTR. Pour faire ceci, j’ai créé un répertoire floapp-website:

Mon image docker est sur une VM qui n’a pas la CA root trustée. Avant de lancer l’upload, je vais devoir truster la CA sous peine d’avoir une erreur de certificat. Utilisez les commandes suivantes pour truster la CA:

export DOMAIN_NAME=dtr.florentappointaire.cloud
openssl s_client -connect $DOMAIN_NAME:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM | tee /usr/local/share/ca-certificates/$DOMAIN_NAME.crt
update-ca-certificates
service docker restart

Je me suis ensuite connecté à mon répertoire, j’ai construis mon image à partir d’un Dockerfile, j’ai taggué l’image et je l’ai poussé:

docker login dtr.florentappointaire.cloud
docker build -t floapp-website .
docker tag floapp-website:latest dtr.florentappointaire.cloud/fappointaire/floapp-website:latest
docker push dtr.florentappointaire.cloud/fappointaire/floapp-website:latest

Si vous retournez sur l’interface de DTR, vous avez maintenant la dernière version disponible:

Vous pouvez maintenant récupérer l’image depuis un nœud UCP, avec la commande suivante ou via l’UCP:

docker pull dtr.florentappointaire.cloud/fappointaire/floapp-website:latest

La vue depuis l’UCP une fois l’envoie terminé:

Vous pouvez maintenant déployer un container depuis l’UCP ou via la ligne de commande:

Après quelques secondes, le conteneur est déployé et vous pouvez y accéder via l’URL:

En espérant que cet article vous sera utile

Voulant utiliser une PKI déjà existante pour mon interface UCP, et n’ayant rien trouvé sur internet si ce n’est le chapitre 4 de la documentation officielle, je vais vous expliquer comment faire ceci.

Les prérequis sont bien sur d’avoir une PKI qui tourne avec AD CS dans mon cas, et ensuite d’avoir une VM qui accueillera l’interface UCP, et où docker-engine est déjà installé.

Pour commencer, il faut installer la librairie openssl sur un ordinateur Windows: http://slproweb.com/download/Win32OpenSSL-1_0_2h.exe

Ensuite, il faut générer le certificat pour notre contrôleur UCP. C’est un certificat de type Web Server. Ajoutez tous les DNS susceptibles d’être utilisés pour accéder à l’UCP:

N’oubliez pas, dans la partie Private Key, de cocher la case pour autoriser l’export de la clé privée:

Il faut maintenant télécharger votre certificat root et exporter le certificat que vous venez de générer avec la clé privée:

Comme sur Linux nous pouvons utiliser que des certificats avec l’extension PEM, on va devoir convertir nos certificats. On va commencer avec le certificat root. Exécutez la commande suivante pour le convertir. Attention a bien nommer le nouveau certificat ca.pem:

cd C:\OpenSSL-Win32\bin
openssl.exe x509 -inform der -in "C:\Users\FlorentAppointaire\Downloads\RootCertificate.cer" -out "C:\Users\FlorentAppointaire\Desktop\ca.pem"

Maintenant nous allons extraire notre clé privée du certificat de base. Ce certificat sera découpé en 2 parties, cert.pem et key.pem:

openssl.exe pkcs12 -in "C:\Users\FlorentAppointaire\Downloads\FLOAPP-UCP01.pfx" -out "C:\Users\FlorentAppointaire\Downloads\cert.pem" –nokeys

openssl.exe pkcs12 -in "C:\Users\FlorentAppointaire\Downloads\FLOAPP-UCP01.pfx" -out "C:\Users\FlorentAppointaire\Downloads\key.pem"

Il faut maintenant supprimer la passphrase du certificat key.pem car docker ne supporte pas cette possibilité:

openssl rsa -in "C:\Users\FlorentAppointaire\Downloads\key.pem" -out "C:\Users\FlorentAppointaire\Desktop\key.pem"

Maintenant que nous avons nos certificats, il faut les transférer sur les serveurs UCP:

Allez sur le premier serveur UCP et créez un nouveau volume Docker:

sudo docker volume create --name ucp-controller-server-certs

Il faut récupérer le chemin de ce volume où nos certificats seront stockés. On va ensuite copier nos certificats dans ce répertoire:

sudo docker volume inspect ucp-controller-server-certs
sudo cp /tmp/* /var/lib/docker/volumes/ucp-controller-server-certs/_data/
sudo ls -l /var/lib/docker/volumes/ucp-controller-server-certs/_data/

Une fois terminé, utilisez la commande suivante pour lancer l’installation de l’UCP. N’oubliez pas le paramètre –external-server-cert pour utiliser les certificats qui sont dans le volume que nous avons créé précédemment:

sudo docker run --rm -it --name ucp -v /var/run/docker.sock:/var/run/docker.sock docker/ucp install -i --host-address 10.0.2.150 --external-server-cert

Si vous accédez à votre interface, vous devriez avec le certificat que vous avez créé est utilisé:

Bon courage

Après avoir vu comment joindre un serveur Ubuntu à un Active Directory nous allons voir comment installer les outils qui permettrons de gérer votre serveur SQL depuis ce dernier. La version que nous allons utiliser, la 13, est compatible avec Ubuntu. Vous pouvez utiliser ces drivers de SQL Server  2008 à 2016, ainsi qu’avec Azure SQL Database.

Pour commencer, installez les prérequis qui seront nécessaires pour l’installation de sqlcmd sur Linux:

sudo apt-get -y install libc6 libkrb5-3 libgss3 e2fsprogs openssl libssl-dev libssl1.0.0 libssl1.0.0-dbg make

Nous allons maintenant télécharger et installer les drivers ODBC Microsoft pour SQL Server pour Linux:

wget https://download.microsoft.com/download/2/E/5/2E58F097-805C-4AB8-9FC6-71288AB4409D/msodbcsql-13.0.0.0.tar.gz
sudo tar -xvzf msodbcsql-13.0.0.0.tar.gz

Déplacez vous ensuite dans le dossier que vous venez d’extraire. Vous devriez avoir un fichier qui se nomme build_dm.sh. Ce fichier va télécharger et compiler les drivers ODBC en version 12.3.1:

cd msodbcsql-13.0.0.0/
ls –l

Exécutez le avec la commande suivante pour télécharger les drivers et effectuer la compilation. Répondez YES à la question pour accepter la licence:

sudo ./build_dm.sh

Comme c’est indiqué, pour terminer l’installation, vous devez exécutez la commande cd /tmp/unixODBC.21454.32315.4074/unixODBC-2.3.1; make install:

Il faut être root pour effectuer ceci. Je vais donc passer root avec la commande sudo –i:

Et lancer la commande indiquée:

cd /tmp/unixODBC.21454.32315.4074/unixODBC-2.3.1; make install

Par défaut, les librairies sont installées dans /usr/lib64. Sortez du root avec la commande exit.

Nous allons maintenant lancer l’installation des drivers ODBC pour SQL Server. Exécutez la commande suivante pour sauvegarder le fichier odbcinst.ini:

ODBCINSTINI=$(odbc_config --odbcinstini)
sudo cp ${ODBCINSTINI} ${ODBCINSTINI}.bck

Avant de lancer l’installation, on va effectuer une vérification pour voir que tous les prérequis soient bien présents:

./install.sh verify

Tout est correct, on va donc pouvoir lancer l’installation avec la commande suivante:

sudo ./install.sh install --accept-license

Avant de pouvoir utiliser l’outil sqlcmd, il nous reste une dernière vérification à effectuer. Exécutez la commande suivante:

cat /etc/ld.so.conf

Si, comme dans mon cas, vous ne voyez pas /usr/lib64, alors il faut le rajouter:

sudo vim /etc/ld.so.conf

Exécutez la commande suivante pour recharger le fichier de configuration que nous venons de modifier:

sudo ldconfig

Vous pouvez vérifier que l’installation est complète avec la commande suivante:

odbcinst -q -d -n "ODBC Driver 13 for SQL Server"

Vous pouvez vous connecter à votre serveur SQL pour effectuer des requêtes, avec la commande suivante:

sqlcmd –S sqlserver.fqdn.local|instancename -Q "SELECT name FROM sys.databases" -U sa

Pour ma part, j’ai un souci d’authentification avec mon compte Active Directory, en utilisant une authentification Windows:

Alors que sur le server SQL, pas de problème:

Je mettrai à jour ce poste quand j’aurai trouvé le problème.

Amusez-vous bien

Aujourd’hui nous allons voir comment joindre un serveur Ubuntu (dans mon cas en version 16.04) à un domaine Active Directory. Ceci peut-être utile dans le cas où vous souhaitez que les administrateurs utilisent leur compte de domaine pour se connecter aux machines, etc.

Pour commencer, connectez vous sur votre serveur et exécutez la commande suivante pour installer les paquets qui permettront de rejoindre le domaine:

sudo apt-get -y install ntp vim ntpdate winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user

Une nouvelle page va s’afficher pour vous demander le nom de votre domaine, renseignez le:

Il faut maintenant régler la date et l’heure pour qu’elle corresponde à l’heure de votre contrôleur de domaine. Editez le fichier ntp.conf et renseignez le nom ou l’ip de votre contrôleur de domaine:

sudo vim /etc/ntp.conf

Redémarrez le service:

sudo service ntp restart

Vous pouvez afficher la date/heure avec la commande date:

Nous allons maintenant configurer la partie Kerberos. Etant donné que la configuration sera nouvelle, nous allons supprimer tous ce qu’il y a dedans et insérer notre configuration. Exécutez les commandes suivantes:

sudo truncate -s0 /etc/krb5.conf
sudo vim /etc/krb5.conf

Adaptez la configuration avec vos valeurs:

[libdefaults]
ticket_lifetime = 24000
default_realm = FLORENTAPPOINTAIRE.CLOUD
default_tgs_entypes = rc4-hmac des-cbc-md5
default_tkt__enctypes = rc4-hmac des-cbc-md5
permitted_enctypes = rc4-hmac des-cbc-md5
dns_lookup_realm = true
dns_lookup_kdc = true
dns_fallback = yes

[realms]
FLORENTAPPOINTAIRE.CLOUD = {
  kdc = floapp-dc01.florentappointaire.cloud
  kdc = floapp-dc02.florentappointaire.cloud
  default_domain = floapp-dc01.florentappointaire.cloud
}

[domain_realm]
.florentappointaire.cloud= FLOAPP-DC01.FLORENTAPPOINTAIRE.CLOUD
florentappointaire.cloud = FLOAPP-DC01.FLORENTAPPOINTAIRE.CLOUD

[appdefaults]
pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
}

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

Sauvegardez le fichier. Nous allons créer un jeton pour un utilisateur de l’AD, qui a les droits de joindre l’ordinateur au domaine. Exécutez la commande suivante:

sudo kinit fappointaire

Et pour vérifier que le jeton a bien été créé, exécutez la commande sudo klist:

Nous allons modifier le fichier de configuration Samba. Si vous souhaitez un nom de machine autre que celui qui se trouve dans /etc/hostname, ajoutez la ligne NetBIOS name = nouveaunomdemachine. Il faut remplacer la ligne workgroup = WORKGROUP du fichier de configuration par la configuration suivante, en adaptant avec vos valeurs:

sudo vim /etc/samba/smb.conf

workgroup = FLORENTAPPOINTA
security = ADS
realm = FLORENTAPPOINTAIRE.CLOUD
encrypt passwords = yes

idmap config *:backend = rid
idmap config *:range = 5000-100000

winbind allow trusted domains = no
winbind trusted domains only = no
winbind use default domain = yes
winbind enum users  = yes
winbind enum groups = yes
winbind refresh tickets = yes

template shell = /bin/bash

Sauvegardez la configuration. Nous allons maintenant modifier le fichier nsswitch.conf pour indiquer que nous allons utiliser les utilisateurs et les groupes de l’active directory (winbind):

sudo vim /etc/nsswitch.conf

Il est maintenant temps de joindre le serveur Ubuntu 16.04 à notre Active Directory. Utilisez la commande suivante:

sudo net ads join –k

OR

net ads join -S FLOAPP-DC01.florentappointaire.cloud -U fappointaire

Vous pouvez ignorer l’erreur concernant le DNS tant que le serveur a bien joint le domaine. Voici l’objet dans l’Active Directory:

Nous allons maintenant vérifier que l’authentification Active Directory est bien activée. Utilisez la commande suivante:

sudo pam-auth-update

Un écran apparaît. Assurez vous que la ligne Winbind NT/Active Directory authtication soit bien sélectionné. J’ai également sélectionnez le fait de pouvoir créer un répertoire par défaut pour chaque utilisateur qui se connectera:

Redémarrons les services pour que toutes les modifications soient prises en compte:

sudo service smbd restart
sudo service nmbd restart
sudo service winbind restart

Vous pouvez utilisez les commandes suivantes pour vérifier qu’il y a bien une synchronisation avec l’Active Directory:

wbinfo -u
wbinfo -g
wbinfo -i fappointaire
getent passwd
getent group

J’ai ensuite ajouté mon utilisateur dans le groupe sudoer:

sudo adduser fappointaire sudo

Vous pouvez vous connecter avec votre compte de domaine sur le serveur Ubuntu et passer root:

Le prochain article portera sur l’installation et l’utilisation de SQLCMD pour gérer vos bases de données SQL Server, directement depuis un serveur Linux

Si vous souhaitez débuter avec les conteneurs sur Windows Server 2016, je viens juste de terminer une vidéo qui explique les premiers pas pour bien débuter. Cette vidéo est disponible ici:

https://channel9.msdn.com/Blogs/MVP-Cloud-DataCenter/Windows-Container-avec-Windows-Server-2016-TP5

N’hésitez pas à me laisser vos commentaires

Avec Windows Server 2016, les containers sont arrivés sous la forme d’une fonctionnalité dans Windows Server. Avec l’arrivée de la TP5, la façon de gérer les containers a changé. En effet, pour la gestion du réseau, on ne fait plus un nouveau switch, mais on utilise la commande New-ContainerNetwork. Pour rajouter une règle de NAT, vous devez utiliser la commande Add-ContainerNetworkAdapterStaticMapping. J’ai donc fait ceci:

$iiscore = Get-Container -Name $containerNameIIS
Add-ContainerNetworkAdapterStaticMapping -Container $iisCore -AdapterName "$containerNameIIS-NetAda" -ExternalPort 80 -InternalPort 80 -Protocol TCP

Seulement, j’ai eu l’erreur suivante:

Add-ContainerNetworkAdapterStaticMapping : The operation failed.

Après avoir cherché pendant plusieurs minutes, j’ai essayé d’éteindre le container et d’exécuter la commande. Cette fois, ça a fonctionné:

J’ai également vérifié que la règle de NAT était bien présente:

Conclusion: Il faut arrêter le container que vous souhaitez modifier au niveau réseau pour que la commande s’effectue correctement.

Ayant acquis un Intel NUC 6th Generation il y a environ 3 semaines, j’ai voulu déployer Windows Server 2016 TP5 sur ce dernier. L’installation s’est déroulé correctement. J’ai téléchargé les drivers depuis mon laptop directement depuis le site de Intel, pour la version Windows 10 64-bits: https://downloadcenter.intel.com/product/89190

Tous les drivers se sont installés correctement, sauf le driver de la carte réseau. J’ai cherché sur Internet et j’ai trouvé la réponse à ma question sur ce poste: http://www.sqlbrander.com/2015/12/08/running-windows-server-2016-ctp4-on-an-intel-nuc-5i5ryh/ Je l’ai donc adapté pour la TP5.

La procédure suivante n’est pas officielle et n’est pas supporté, ne l’utilisez pas pour un environnement de production.

Le but ici est de commencer en désactivant la vérification de la signature des drivers, avec les commandes suivantes:

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING ON
bcdedit /set nointegritychecks ON

Redémarrez le serveur. Téléchargez le driver de la carte réseau iciet ouvrez le fichier, de façon à avoir les sources du driver:

On va maintenant modifier le driver réseau. Le driver se trouve dans le dossier Your_Directory\LAN_Win10_64_20.7.1\PRO1000\Winx64\NDIS65. Pour Windows Server 2016 TP5, nous allons modifier le fichier e1d65x64.inf. Ouvrez le et cherchez les lignes suivantes:

[ControlFlags]
ExcludeFromSelect = \
    PCI\VEN_8086&DEV_153A,\
    PCI\VEN_8086&DEV_153B

Remplacez les par:

[ControlFlags]

Copiez les lignes suivantes:

%E15A0NC.DeviceDesc%            = E15A0.10.0.1,       PCI\VEN_8086&DEV_15A0
%E15A0NC.DeviceDesc%            = E15A0.10.0.1,       PCI\VEN_8086&DEV_15A0&SUBSYS_00008086
%E15A1NC.DeviceDesc%            = E15A1.10.0.1,       PCI\VEN_8086&DEV_15A1
%E15A1NC.DeviceDesc%            = E15A1.10.0.1,       PCI\VEN_8086&DEV_15A1&SUBSYS_00008086
%E15A2NC.DeviceDesc%            = E15A2.10.0.1,       PCI\VEN_8086&DEV_15A2
%E15A2NC.DeviceDesc%            = E15A2.10.0.1,       PCI\VEN_8086&DEV_15A2&SUBSYS_00008086
%E15A2NC.DeviceDesc%            = E15A2.10.0.1,       PCI\VEN_8086&DEV_15A2&SUBSYS_00011179
%E15A3NC.DeviceDesc%            = E15A3.10.0.1,       PCI\VEN_8086&DEV_15A3
%E15A3NC.DeviceDesc%            = E15A3.10.0.1,       PCI\VEN_8086&DEV_15A3&SUBSYS_00008086
%E15A3NC.DeviceDesc%            = E15A3.10.0.1,       PCI\VEN_8086&DEV_15A3&SUBSYS_00011179
%E156FNC.DeviceDesc%            = E156F.10.0.1,       PCI\VEN_8086&DEV_156F
%E156FNC.DeviceDesc%            = E156F.10.0.1,       PCI\VEN_8086&DEV_156F&SUBSYS_00008086
%E156FNC.DeviceDesc%            = E156F.10.0.1,       PCI\VEN_8086&DEV_156F&SUBSYS_00011179
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179
%E15B7NC.DeviceDesc%            = E15B7.10.0.1,       PCI\VEN_8086&DEV_15B7
%E15B7NC.DeviceDesc%            = E15B7.10.0.1,       PCI\VEN_8086&DEV_15B7&SUBSYS_00008086
%E15B7NC.DeviceDesc%            = E15B7.10.0.1,       PCI\VEN_8086&DEV_15B7&SUBSYS_00011179
%E15B8NC.DeviceDesc%            = E15B8.10.0.1,       PCI\VEN_8086&DEV_15B8
%E15B8NC.DeviceDesc%            = E15B8.10.0.1,       PCI\VEN_8086&DEV_15B8&SUBSYS_00008086
%E15B8NC.DeviceDesc%            = E15B8.10.0.1,       PCI\VEN_8086&DEV_15B8&SUBSYS_00011179

Et collez les après le bloc suivant:

[Intel.NTamd64.10.0]
; DisplayName                   Section        DeviceID
; -----------                   -------        --------
%E153ANC.DeviceDesc%            = E153A,       PCI\VEN_8086&DEV_153A
%E153ANC.DeviceDesc%            = E153A,       PCI\VEN_8086&DEV_153A&SUBSYS_00008086
%E153ANC.DeviceDesc%            = E153A,       PCI\VEN_8086&DEV_153A&SUBSYS_00011179
%E155ANC.DeviceDesc%            = E155A,       PCI\VEN_8086&DEV_155A
%E155ANC.DeviceDesc%            = E155A,       PCI\VEN_8086&DEV_155A&SUBSYS_00008086
%E155ANC.DeviceDesc%            = E155A,       PCI\VEN_8086&DEV_155A&SUBSYS_00011179
%E15A0NC.DeviceDesc%            = E15A0,       PCI\VEN_8086&DEV_15A0
%E15A0NC.DeviceDesc%            = E15A0,       PCI\VEN_8086&DEV_15A0&SUBSYS_00008086
%E15A2NC.DeviceDesc%            = E15A2,       PCI\VEN_8086&DEV_15A2
%E15A2NC.DeviceDesc%            = E15A2,       PCI\VEN_8086&DEV_15A2&SUBSYS_00008086
%E15A2NC.DeviceDesc%            = E15A2,       PCI\VEN_8086&DEV_15A2&SUBSYS_00011179
%E156FNC.DeviceDesc%            = E156F,       PCI\VEN_8086&DEV_156F
%E156FNC.DeviceDesc%            = E156F,       PCI\VEN_8086&DEV_156F&SUBSYS_00008086
%E156FNC.DeviceDesc%            = E156F,       PCI\VEN_8086&DEV_156F&SUBSYS_00011179
%E15B7NC.DeviceDesc%            = E15B7,       PCI\VEN_8086&DEV_15B7
%E15B7NC.DeviceDesc%            = E15B7,       PCI\VEN_8086&DEV_15B7&SUBSYS_00008086
%E15B7NC.DeviceDesc%            = E15B7,       PCI\VEN_8086&DEV_15B7&SUBSYS_00011179

Vous devriez avoir ceci:

Sauvegardez le fichier et allez dans le Device Manager, sur votre carte réseau. Choisissez Update Driver:

Choisissez la 2ème option pour sélectionner le driver créé précédemment:

Donnez le chemin vers votre driver:

Vous allez avoir un message pour dire que le driver représente un risque, installez quand même:

Le driver est maintenant installé:

Vous pouvez donc accéder au réseau, via votre Intel NUC sur Windows Server 2016 TP5.

La dernière étape est de réactiver la vérification de la signature des drivers, avec les commandes suivantes:

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING OFF
bcdedit /set nointegritychecks OFF

Redémarrez le serveur. Et voila, vous avez maintenant le réseau ethernet qui fonctionne sur votre serveur.

En espérant vous avoir aidé