Hello a tous,
 
alors que je suis en train de préparer une migration d'AD, je me rends compte que les nouveaux contrôleurs de domaine sont inaccessibles en IP \\ip.du.serveur . en DNS, pas de soucis.
Sur les anciens controleurs de domaine, pas de pb, ip ou DNS ça passe.
En poussant un peu je me rends compte que même les serveurs installés récemment sont inaccessible en ip. ils repondent bien au ping, les shares sont accessibles via DNS name, mais par IP rien.
 
D'un poste local à un serveur, d'un serveur à un serveur, d'un DC à un DC, le comportement est similaire.
 
Dans l'absolu vous me direz c'est pas bien grave sauf que Veeam a priori il aime pas trop, et la sauvegarde avec AAP des nouveaux DC foire lamentablement, avec un message type "path not found" ; c'est d'ailleurs le message que j'ai quand je fais un \\ip.du.serveur
 
Sur les PC, pas de soucis.
 
Donc j'en viens à la conclusion qu'il y a une GPO quelque part qui vient m'empêcher de faire ça... mais pour l'instant pas trouvé.
 
Vous auriez une idée lumineuse? (bon on est vendredi soir, y'a peut être un rapport....)
 
Merci!
 

Jamais une bonne idée d'utiliser l'ip directement, tu peux pas faire de kerberos comme ça.

L'accès au partage via IP se fait obligatoirement avec NTLM. Il faut donc que celui-ci n'ai pas été désactivé.

Mais je ne suis pas sûr que ce soit suffisant, car de mon côté c'est pareil, ça ne fonctionne pas. On trouve moult sujets sur le net à propos de ça et il n'y pas vraiment de réponse universelle, des fois c'est des MAJ qui ont foutu le boxon ou encore des services désactivés (genre netBIOS). Toujours est-il que je n'ai pas réussi à le refaire fonctionner pour l'instant.

EDIT : À force de bidouiller je me suis mélangé les GPO et j'avais défini 2 fois la désactivation de NTLM dans celle du domaine et des contrôleurs. Une fois tout ça remis par défaut ça fonctionne sans problème :

 
C'est veeam qui a l'air de vouloir en faire... A part ce pb de backup de mes VM DC tput fonctionne bien.
 
Peut être que ça a rien a voir mais ça semble quand même sacrément corrélé vu les msg d'erreur de veeam.

 
Hello
 
Merci pour ça mais justement, ça voudrait dire que NTLM est activé sur mes anciens DC et autres serveurs et rien sur aucuns nouveau ?  
 
Ça me semble bizarre...

Pas de raison que Veeam ait besoin d'un accès en IP pour un backup. Tu as vérifié les propriétés du job ? Tu as configuré un compte de service ?
Tous tes DC ont bien le même OS, le même niveau de patch, la même configuration ?
 
Edit : si tu as désactivé NTLM, effectivement veeam part dans les choux. Soit tu le réactives (risque sécu), soit tu attends la V12 qui va enfin gére rle Kerberos only (et les gMSA).

Pour vérifier, c'est dans les stratégies de sécurité, mais en théorie même sur 2022, c'est pas désactivé :

un gpresult /R serait plus utile pour savoir d'où viennent les settings configurés.
Sinon https://forums.veeam.com/microsoft- [...] 03-30.html

Il me semble que c'est possible depuis quelques temps ça

Ouais mais j'imagine mal qu'il ait configuré ça
A éviter qd même

Bon ça avance!
 
https://helpcenter.veeam.com/docs/b [...] ml?ver=110
 
Et j'ai trouvé une gpo (qui date) qui en effet désactive NTLM... enfin du moins en partie, puisque pour tous les "anciens" serveurs ça n'a pas l'air appliqué, et sur les nouveaux ça ne devrait pas non plus puisque c'est rattaché à des UO "computers" et pas servers. A moins que ça ait été collé ailleurs... va falloir que j'épluche les gpo.
 
 
Et sinon passer à Veeam 12 dès qu'il est dispo...

Heu... arrêtez moi si je dis une connerie, mais je crois qu'il il n'y a pas de distinction entre computer (au sens client) et servers.

Si tu regarde dans ADUC, les DC par ex, sont classés computer. Ce n'est pas parce qu'une UO leur est dédiée par défaut qu'ils sont traités différemment. Tu peux très bien les déplacer dans une autre UO et l'appeler tartempion ça fonctionnera tout aussi bien.

Lors de ton épluchage, pense aussi aux policy locales, je me suis fait eu l'autre fois. Mettre en non défini la GPO ne la remet pas par défaut pour autant, car si en local c'était une autre valeur, alors elle se réapplique.  Piégeux à souhait  

Hello, pour vous tenir au jus, c'est résolu.  
 
Je crois savoir ce qui s'est passé : les anciens DCs (2012R2) n'avaient pas de config par défaut concernant NTLM, donc tous settings en "not defined", l'autorisant donc.  
 
Les DC2022 en revanche doivent avoir des paramètres différents par défaut, notamment NTLM :  authentification on this domain qui doit être par défaut en deny all.
 
Ce que j'avais pas compris, et sur lequel je m'acharnait avec GPO ou autre SECPOL.Msc sur les serveurs membres,  c'est que ce paramètre ne "concerne" en fait a priori que les DC...  Dès lors que j'ai repassé le paramètre en disable sur les nouveaux DC, boom, tout fonctionne à nouveau.
 
Du coup l'idée c'est de remettre ça bien propre par GPO pour plus tard, et surtout que NTLM soit facile à désactiver dès qu'on aura pu passer en Veeam 12 avec support kerberos!
 
A+

Bizarre.  
 
J'ai refait le test pour être sûr et sur une fresh install, le NTLM n'est pas bloqué. Le seul paramètre qui change (ça date de vista à priori) c'est le NTLMv2 par défaut (niveau 3) et encore ça ne concerne que les clients/serveurs standalone. Un DC accepte toujours LM/NTLMv1, car un XP par ex, peut toujours se connecter en IP avec LM&NTLM
 
Concernant  authentification on this domain qui n'a d'effet que sur les DC, ça parait logique.