Chrisdu80

Bonjour, Merci pour vos réponses, Le 389 n'est pas utilisé pour le RDS c'est le 3389 et il est utilisé en entrée. La solution du firewall Microsoft n'a aucun effet même en bloquant tout le trafic. Pour ce qui est de PVE, le client loue une licence Windows, si je retire Windows la licence ne peut pas être attribué à une VM donc j'oblige le client à acheter une licence. Je vais mettre une VM sous linux avec un vlan pour mes serveurs et une IP public unique sur cette VM avec redirection des ports, comme ça cela règle mon problème.

Bonjour, J'ai actuellement un serveur Windows 2012R2 standard chez un client avec l'AD dessus. Ce serveur est en ligne avec un hébergement chez OVH, c'est un serveur dédié. Il subit très souvent des attaques sur le port 389 par rebond ( voir article ) et l’hébergeur lui coupe régulièrement son serveur. J'ai fait des règles dans le Firewall afin de ne plus entrer/sortir sur le port 389 sur tout les réseaux. J'ai fait un nmap du serveur et le port 389 n'était plus ouvert/listé, malheureusement et sans modification de mon client ou moi, les attaques ont repris ce week-end et le serveur et de nouveau down. Comment je peux arrêter ce genre de problème ?

Salut, J'ai le Zalman et j'ai déjà eu le problème et je l'ai réglé en remplaçant l'ISO par une nouvelle téléchargé directement chez Microsoft.

Bonjour, Je ne sais pas si tu as trouvé la solution à ton problème mais comment as-tu réglé le mode d’attribution des ordinateurs aux groupes dans WSUS ? Cela se trouve dans les options de ton WSUS -> Options -> Ordinateurs Et pense à créer des noms de groupe identique à tes OU dans l'AD

Salut, Tu n'aurais pas une GPO d'active ? ou un nombre limité de session par utilisateur ?

Netdom en force ca à l'air de fonctionner. Il me faut maintenant trouver un créneau de reboot du serveur pour vérifier si cela fonctionne. Merci de ton aide en tout cas

Je ne peux pas la sortir du reseau les vms sont en production et le serveur est a 250km de moi

J'ai 2 cartes réseaux 10Go une pour le management et une pour les VMs .

Et si je modifie la base de registre cela risque d’être dangereux ?

Meme problème

Voila la capture de l'erreur

J'ai essayé de créer le compte ordinateur à la main mais non La commande powershell: Add-Computer -DomainName Domain01 -Server Domain01\DC01 -PassThru -Verbose J'ai essayer aussi à l'instant d’intégrer mon serveur Core depuis l'AD en powershell: Add-Computer -ComputerName Server01 -LocalCredential Server01\Admin01 -DomainName Domain02 -Credential Domain02\Admin02 -Restart -Force Toujours le même souci.

Bonjour, J'ai actuellement un serveur Windows 2012R2 Core Hyper-V V3 (sans interface graphique) avec des VMs pour différents clients. Ce serveur était dans un domaine. Seulement aujourd'hui mon serveur AD n'est plus la (hacké et formaté) et bien sur le client n'a pas de sauvegardes... J'ai remonté un nouvel AD sur un nouveau serveur et je souhaite réintégrer mon serveur Windows 2012R2 Core. Quand j'essai de le sortir de son ancien domaine vers le nouveau serveur, il me dit que le domaine (son ancien) n'est pas joignable. Et si je veux joindre mon nouveau domaine directement, même problème. J'ai essayer depuis l'interface en ligne de commande du serveur pour le passer de domaine à workgroup -> même soucis J'ai essayer en powershell avec add-computer --> même soucis Il n'y aurait pas un autre moyen ?

Bonjour à tous, Je prépare la mise en place d'un serveur linux / nginx pour faire du proxy reverse vers une zone DMZ, le tout en SSL. Tous mes serveurs sont stockés sur un Hyper-V, j'ai aussi une IP publique, un seul nom de sous-domaine. Concernant le nom de sous-domaine, je n'ai pas le choix, s’est imposé. Donc pour ma configuration de Nginx je vais utiliser des redirections vers des ports spécifique. Mon serveur Nginx est une VM derrière un Firewall physique, il n’a donc qu’une carte réseau vue que l’accès externe se fera par le biais d’une authentification dur (OTP) avec VPN. Ce serveur sera accessible depuis un WAN privé. Le Nginx est le seul serveur qui peux discuter avec la zone DMZ depuis l’extérieur (configuration sur le Firewall) Dans ma zone DMZ (IP non réel) : 192.168.253.2 à serveur Web (opérationnel sous Ubuntu / Apache2) 192.168.253.5 à serveur NextCloud (opérationnel sous Ubuntu / Apache2) 192.168.253.6 à serveur OnlyOffice (opérationnel sous Ubuntu / Apache2) Voici la configuration du fichier Nginx (Nom de domaine et IP non réel) : "vim /etc/nginx/sites-available/default" Configuration de base + SSL: server { listen 80; return 301 https://$host$request_uri; } server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2; server_tokens off; ssl on; server_name sousdomain.domain.com; access_log /var/log/nginx/nginx.certif-ssl.access.log; error_log /var/log/nginx/nginx.certif-ssl.error.log warn; root /var/www/html; index index.php index.html index.htm index.nginx-debian.html; location / { try_files $uri $uri/ /index.php?q=$uri&$args; # On cache les fichiers statiques location ~* \.(html|css|js|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires max; } # On interdit les dotfiles location ~ /\. { deny all; } } ## PHP location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/run/php/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_read_timeout 60; } ## SSL ssl_certificate /etc/nginx/ssl/bundle.crt; ssl_certificate_key /etc/nginx/ssl/certif-ssl_mondomain_com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; ssl_session_tickets off; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_prefer_server_ciphers on; resolver 8.8.8.8 8.8.4.4; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/bundle.crt; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Powered-By "Mon PHP !"; } La redirection du http vers le https fonctionne parfaitement et le certificat est testé sur www.ssllabs.com est de catégorie A. Maintenant la partie reverse proxy vers les serveurs. server { listen 8082; server_name sousdomain.domain.com; location / { proxy_pass http://192.168.253.2:8082; proxy_redirect off; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Url-Scheme $scheme; } location ~*^.+(swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ { proxy_pass http://192.168.253.2:8082; proxy_set_header Host $http_host; } } Sur cette redirection, on utilise l'adresse http://sousdomain.domain.com:8082 pour retourner vers http://192.168.253.2:8082, cela fonctionne j'ai bien ma page de test Apache2 à l'écran. server { listen 8086; server_name sousdomain.domain.com; location / { rewrite /nextcloud/(.*) /$1 break; proxy_pass https://192.168.253.6; proxy_redirect http:// https://; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Url-Scheme $scheme; } location ~*^.+(swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ { proxy_pass http://192.168.253.6; proxy_set_header Host $host; } } Sur cette redirection , on utilise l'adresse https://sousdomain.domain.com:8086 pour retourner vers https://192.168.253.6, ici ca pose un problème. Quand je vais sur la page https://192.168.253.6 le site fonctionne bien, si je vais sur https://sousdomain.domain.com:8086 j'ai une erreur ERR_TUNNEL_CONNECTION_FAILED Sur mon 3em serveur j'ai une configuration équivalente et j'ai le même souci. Je pense que ma redirection SSL pose problème mais je galère ;). Si quelqu'un peux d'aider je l'en remerci d'avance.

je vous donnerais plus d'infos quand on avancera coté projet