1 14/10/2026 10 min

DAV 401/405 in SCCM: il punto non è “SCCM rotto”, ma dove si interrompe la richiesta

Quando in SCCM compare un errore DAV 401 o 405, il problema quasi mai è nel singolo messaggio mostrato a schermo. Quello che conta è capire in quale tratto del percorso si rompe la richiesta: autenticazione, autorizzazione, metodo HTTP non accettato, filtro IIS, WebDAV, reverse proxy o policy lato client. Se si parte dalla sintomatologia e non dal layer, si finisce a cambiare impostazioni a caso e ad allargare il raggio d’impatto senza chiudere il guasto.

In pratica, 401 significa che il server non accetta o non riesce a validare l’identità del client. 405 significa che il server riconosce la risorsa ma rifiuta il metodo usato, per esempio PUT, PROPFIND, DELETE o altre chiamate DAV che passano da componenti IIS/WebDAV o da un proxy intermedio. In SCCM questo si vede spesso durante operazioni di content distribution, accesso a repository, upload verso un endpoint WebDAV, sincronizzazione con un sistema di gestione documentale o integrazioni che passano da IIS.

Prima distinzione utile: 401 e 405 non hanno la stessa causa

Il modo più rapido per non perdere tempo è separare il caso in due famiglie. Il 401 punta quasi sempre a credenziali, token, Kerberos/NTLM, delega o autorizzazione su IIS. Il 405 punta invece a un problema di verbo HTTP, handler, modulo WebDAV, request filtering o regole del reverse proxy. Se il messaggio è “DAV 401 405”, spesso il client sta tentando una sequenza di richieste e una parte fallisce per identità, un’altra per metodo non consentito.

Il dettaglio che aiuta di più è il log. Su IIS, i codici si leggono nei log di sito in `C:\inetpub\logs\LogFiles\W3SVC*\u_ex*.log`. Nella colonna sc-status trovi il codice principale; sc-substatus e sc-win32-status dicono se il blocco arriva da autenticazione, filtro o autorizzazione NTFS. Se il 401 ha substatus 2, 3 o 5, sei più vicino a un problema di accesso o permessi che a un guasto di SCCM. Se il 405 compare con richieste DAV, il sospetto va subito su WebDAV o su una restrizione del metodo nel sito IIS o nel proxy davanti.

Dove guardare per primo: layer, evidenza minima e falsificazione rapida

Il primo controllo non è la console SCCM, ma la catena completa della richiesta. Serve capire se il problema nasce sul client, sul listener IIS, sul proxy, o dentro il sito applicativo. Se hai accesso al server, una richiesta sintetica con header e risposta basta già a restringere molto il campo.

curl -I https://FQDN-del-servizio/endpoint
curl -v -X OPTIONS https://FQDN-del-servizio/endpoint

Se il 401 arriva subito, senza arrivare al contenuto applicativo, controlla autenticazione e autorizzazione. Se il server risponde con 405 a OPTIONS o a un verbo DAV, il problema è nel supporto al metodo. Se invece la risposta cambia tra accesso diretto al server e accesso via FQDN pubblico, il punto è quasi certamente il proxy o il bilanciatore.

Su Windows Server e IIS, la traccia da aprire è il log del sito coinvolto, più l’Event Viewer nei rami Application e System. Per un controllo veloce, cerca eventi IIS o errori di autenticazione nello stesso intervallo temporale del tentativo fallito. Se il servizio è dietro reverse proxy, verifica anche i log del front-end: spesso è lì che il metodo viene filtrato prima ancora di arrivare a IIS.

Cause probabili in ordine pratico

In un contesto SCCM, le cause più frequenti si ripetono quasi sempre nello stesso ordine. La prima è l’autenticazione IIS non coerente con il tipo di client che sta chiamando il servizio: browser, agent, task sequence, connettore esterno o integrazione custom. La seconda è WebDAV abilitato o disabilitato nel punto sbagliato. La terza è un filtro HTTP o un proxy che blocca i metodi usati dal client.

  • Autenticazione IIS: Anonymous, Windows Authentication, Basic o Kerberos impostati in modo non compatibile con il flusso.
  • WebDAV: modulo installato e attivo dove non serve, oppure rimosso dove il client si aspetta metodi DAV.
  • Request Filtering / proxy: metodi HTTP bloccati, header rimossi, body troppo grande, limiti su verb o content length.

Una nota pratica: il 405 non significa sempre “il server non supporta quel verbo”. A volte significa che il verbo è supportato dal sito, ma viene neutralizzato da un modulo IIS, da una regola URL Rewrite o da un proxy esterno che riscrive o sopprime le richieste. Per questo il test diretto sul server, bypassando il front door, è il più utile.

Controlli mirati su IIS: autenticazione, WebDAV e metodi consentiti

Se il servizio SCCM passa da IIS, il controllo va fatto in tre punti: autenticazione del sito, presenza del modulo WebDAV e limiti dei metodi consentiti. Dal punto di vista operativo, non serve toccare subito la configurazione: prima leggi lo stato, poi cambi solo il componente che falsifica il test.

In IIS Manager, apri il sito interessato e verifica Authentication. Se il client usa Windows Integrated Authentication, controlla che Windows Authentication sia abilitata e che il provider atteso sia disponibile. Se il client è esterno e si aspetta Basic o un altro schema, la combinazione va verificata con attenzione, perché una modifica qui ha impatto diretto sugli accessi.

Poi verifica WebDAV Authoring Rules e il modulo WebDAV a livello di server. In molti casi WebDAV non deve esserci proprio. Se il sito SCCM non usa DAV, lasciare il modulo attivo è rumore operativo: può intercettare metodi che il sito non deve gestire e restituire 405 in modo ambiguo. Se invece l’integrazione richiede DAV, il modulo deve essere presente e configurato in modo coerente con i metodi e i permessi previsti.

Per un controllo da riga di comando, su un server IIS puoi verificare i moduli installati e lo stato del servizio con questi comandi.

Get-WindowsFeature Web-DAV-Publishing
Get-WebGlobalModule | Select-Object Name
Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter 'system.webServer/security/requestFiltering/verbs' -name '.'

Se Web-DAV-Publishing risulta installato ma non serve al flusso, quella è una pista concreta. Se i verbi sono filtrati da request filtering, il 405 può essere la semplice conseguenza di una deny list troppo stretta.

Quando il problema è il proxy o il bilanciatore

Molti casi “DAV 401 405” in realtà nascono davanti a IIS, non dentro IIS. Un reverse proxy può togliere l’header di autorizzazione, cambiare il metodo, comprimere o normalizzare le richieste, bloccare verb non standard o riscrivere l’URL in modo che il backend veda una risorsa diversa da quella richiesta dal client. Se il problema sparisce accedendo direttamente all’origine e riappare passando dal front-end, la diagnosi è quasi fatta.

Il test più semplice è confrontare due chiamate uguali, una verso l’origine e una verso il nome pubblico. Se l’origine risponde correttamente e il nome pubblico no, il raggio di ricerca si restringe subito al proxy, al load balancer o al WAF. In questa fase non serve cambiare la configurazione: basta raccogliere evidenza.

curl -vk https://origin-interna/endpoint -H 'Host: fqdn-pubblico'
curl -vk https://fqdn-pubblico/endpoint

Se il proxy è Nginx, Apache, ARR o un appliance, controlla i log di accesso e le regole che trattano i metodi HTTP. In particolare, cerca blocchi su PROPFIND, LOCK, UNLOCK, PUT e DELETE. Se il bilanciatore termina TLS e reinvia verso IIS, verifica che l’header Authorization e i metodi non vengano filtrati o normalizzati. Un 401 dietro proxy può essere solo un header perso; un 405 può essere un verb soppresso prima dell’arrivo al backend.

Procedura di risoluzione con modifica minima e reversibile

Qui conviene muoversi con una logica da change controllato. Non si tocca tutto insieme. Si parte dal componente che ha la probabilità più alta di generare il sintomo e si applica la modifica minima, verificando subito la risposta. Se il test fallisce, si torna indietro senza lasciare il sistema in uno stato intermedio difficile da leggere.

  1. Salva lo stato attuale della configurazione IIS del sito coinvolto. Se lavori da shell, esporta almeno i parametri del sito o documenta le opzioni correnti prima di cambiare qualcosa.
  2. Verifica se WebDAV è realmente richiesto. Se non lo è, disabilita il modulo o rimuovi la feature dal server, poi riprova la stessa richiesta che generava 405.
  3. Controlla l’autenticazione del sito. Se il 401 riguarda un client interno, verifica la coerenza tra Windows Authentication e l’identità usata dal processo o dall’utente. Se il client è esterno, verifica che lo schema richiesto sia quello previsto.
  4. Rimuovi o allenta temporaneamente solo il filtro che blocca il verbo necessario, non tutta la policy di request filtering. L’obiettivo è far passare il singolo metodo utile, non aprire il sito indiscriminatamente.
  5. Se il problema passa dal proxy, correggi la regola solo su quel percorso o su quel virtual host, non a livello globale.

La verifica va rifatta con la stessa richiesta che falliva prima. Se stai agendo su un endpoint DAV, usa lo stesso verbo e gli stessi header. Se stai correggendo un 401, riprova con lo stesso account o con lo stesso token. Cambiare client o cambiare metodo durante il test falsa il risultato.

Esempio operativo: leggere il log IIS senza andare a tentoni

Mettiamo che il client riceva un 401.2 quando prova ad accedere a un endpoint SCCM pubblicato su IIS. Nel log trovi una riga con sc-status=401, sc-substatus=2. Questo di solito indica un problema di autenticazione. Prima di cambiare permessi NTFS, verifica il tipo di autenticazione del sito e il provider attivo. Se invece trovi 405 su una richiesta PROPFIND, il primo sospetto è WebDAV o il blocco del verbo, non il database e non il service account.

Un dettaglio che spesso accelera la diagnosi è il confronto tra i codici 401.1, 401.2, 401.3 e 405. Il primo parla di credenziali, il secondo di configurazione di autenticazione, il terzo di autorizzazione NTFS o ACL, il quarto di metodo non consentito. Se il ticket contiene solo “DAV 401 405”, il lavoro vero è ricostruire quale di questi sottocasi sta emergendo sul sito specifico.

Controlli finali: cosa deve essere vero prima di chiudere l’incidente

La chiusura corretta non è “non vedo più l’errore”. Deve esserci una verifica oggettiva che il flusso sia tornato coerente. Il minimo sindacale è una risposta HTTP attesa, l’assenza di nuovi 401/405 nei log e il successo dell’operazione SCCM che prima falliva.

  • La richiesta di test restituisce il codice atteso, non più 401 o 405.
  • Nei log IIS non compaiono nuovi errori sullo stesso endpoint nel medesimo intervallo.
  • Il client SCCM completa l’operazione che prima falliva, senza workaround temporanei.

Se hai rimosso WebDAV o modificato l’autenticazione, tieni presente il blast radius: altri siti sullo stesso server potrebbero dipendere da quella stessa feature. Il rollback deve essere esplicito e veloce: ripristino della feature IIS, reintroduzione del modulo, ripristino della vecchia policy o ritorno alla configurazione salvata prima del change. Se il fix è stato fatto sul proxy, conserva il diff della regola modificata e il punto esatto di rollback.

Assunzione operativa: il caso descritto riguarda un endpoint IIS o un front-end che espone SCCM o un’integrazione collegata a SCCM; se il vostro flusso usa un componente diverso, la stessa logica di diagnosi resta valida ma vanno adattati i log e i controlli del layer applicativo.