Configurazione per account Windows mappato all'autorizzazione del certificato IIS

3

Ho bisogno di connettere due server in posizioni diverse in modo che uno di essi (stack Linux) rilasci richieste periodiche HTTP all'altro (stack Windows) usando i lavori basati su cron .

Sul computer Windows, ho intenzione di configurare un IIS con un certificato autofirmato per autenticare il client (bloccando il certificato) e crittografare la connessione su SSL.

Sto anche configurando IIS per richiedere il certificato client per autenticare il server Linux. Ho seguito un tutorial per configurare l'autenticazione del certificato che prevede il mapping del certificato a un account utente.

Non mi piace l'idea di avere un account utente creato per un server remoto perché non vorrei che qualcuno si connettesse al server (Windows) con quell'account.

Tenendo presente questo, se devo davvero creare un account sul computer Windows, come dovrei configurarlo in modo che possa essere utilizzato solo per autenticare le richieste di IIS dal server Linux?

    
posta Juan 11.09.2018 - 17:41
fonte

2 risposte

1

Hai ragione a preoccuparti di creare un nuovo account utente solo per questa attività. Un approccio molto più semplice consiste nell'utilizzare una chiave di applicazione inserita nell'intestazione della richiesta. Poiché utilizzi certificati autofirmati, ciò mi porta a credere che si tratti di una soluzione una tantum e che non verrà ridimensionata a centinaia di client. Ecco i passaggi per farlo accadere.

AGGIORNAMENTO: questa soluzione alternativa non avrà alcun impatto sull'applicazione ospitata da IIS, poiché URL Rewrite elaborerà la richiesta prima dell'applicazione. Per eliminare immediatamente i tentativi falliti, aggiorna la sezione azione della regola Riscrivi dell'URL al seguente. Si noti che ciò causerà la mancata visualizzazione delle richieste non riuscite nei log di IIS.

<action type="AbortRequest" />

Installa riscrittura URL su IIS

Questo è un modulo Microsoft che non è installato di default e fornisce funzionalità simili a mod_rewrite.

link

Crea regola di riscrittura degli URL

Aggiungi la seguente regola al web.config per la tua applicazione. Cercherà un'intestazione di richiesta di AppAuthKey (che puoi modificare / personalizzare) e un valore di joshua (non distingue tra maiuscole e minuscole e dovrebbe essere qualcosa di più complesso). Se uno dei due non è presente, verrà restituito il 401.4.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
                    </conditions>
                    <action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Modifica comando arricciatura

Aggiorna il comando arricciatura per includere l'intestazione della richiesta come segue:

curl -H "AppAuthKey: joshua"

Nessuna necessità di un certificato client

L'utilizzo di questo metodo non richiede un certificato client. Normale SSL (dovrebbe essere TLS1.2) sarà sufficiente fino a quando utilizzi cifrari forti. Ulteriori informazioni a riguardo sono disponibili nella seguente pagina OWASP:

link

AGGIORNAMENTO # 2

@AlphaD evidenzia punti positivi relativi alle varie impostazioni dei criteri che è possibile utilizzare per limitare ulteriormente gli account. Vorrei raccomandare contro questo dato che va contro la gestione della configurazione. Adottare questo approccio introduce i requisiti di configurazione per il sistema che ospita l'applicazione web che potrebbe o meno influenzare altri servizi. Il metodo preferito è quello di progettare l'app Web per la portabilità in modo che sia necessario poco del sistema di hosting. Supponiamo che abbia senso evidenziare alcuni punti chiave sul motivo per cui è preferibile utilizzare una chiave di applicazione in questa istanza piuttosto che un account utente locale o di dominio su IIS.

Utente locale

Se l'utente è locale solo al server Web che ospita IIS, quell'account sarà in grado di autenticarsi su qualsiasi altro sito Web e / o servizio ospitato da quel server. Assicurati che le autorizzazioni su tutte le altre risorse siano esaminate perché, per impostazione predefinita, l'account sarà membro del gruppo locale "Utenti" che ha una larghezza sorprendentemente ampia. Inoltre questo account ha accesso in lettura sul file system (NTFS). Se un altro sito web non è configurato correttamente, questo utente potrebbe essere utilizzato per autenticare e leggere il suo contenuto. L'autenticazione tramite questo account molto probabilmente utilizzerà l'autenticazione di base, il che significa che le credenziali sono codificate Base64 (non crittografate) e inserite in ogni intestazione di richiesta. (Proprio come la mia raccomandazione di aggiungere un'intestazione di richiesta personalizzata per l'autenticazione.) Infine, l'utilizzo di account utente locali rende difficile la gestione del sistema. Quando si esegue la migrazione del sito Web a un nuovo server, è necessario creare un nuovo account con autorizzazioni aggiornate e con ambito appropriato. Quelle informazioni di accesso devono quindi essere aggiornate negli script di ricciolo consumante. Non rende la tua applicazione portatile.

Utente dominio

Come per l'utente locale, ora l'ambito in cui questo utente può autenticarsi è stato esteso all'intero dominio. Ciò include l'accesso in lettura a gran parte della directory attiva e di altri servizi pubblicizzati nell'ambiente. L'autenticazione con questo utente sarà un po 'più sicura poiché NTLM o Kerberos possono essere utilizzati a condizione che AD sia accessibile e che l'host Linux sia configurato per l'autenticazione AD. Altrimenti sarà probabilmente utilizzata l'autenticazione di base. La gestione degli account diventa un po 'più semplice poiché rientrerà nel dominio della gestione degli account di dominio invece della gestione degli account di sistema e spesso (non sempre) ci sono procedure consolidate per la gestione degli account di dominio.

Chiave dell'applicazione

Metodo preferito poiché non è richiesto alcun account utente e limita l'ambito solo a questa applicazione. Rendere il punto debole il canale di comunicazione (protetto tramite TLS e cifrari forti) e la directory dei contenuti che dovrebbe comunque avere accesso limitato.

    
risposta data 13.09.2018 - 23:12
fonte
1

Da quello che posso capire della tua domanda, stai chiedendo un metodo per generare un utente di Windows Server senza consentire il login o altre autorizzazioni normalmente concesse.

In tal caso, puoi farlo impostando la politica locale per quell'utente in Pannello di controllo > Strumenti di amministrazione > Politica di sicurezza locale. Nel menu a sinistra vai a Criteri locali > Assegnazioni diritti utente. Aggiungi l'utente al criterio "Nega accesso locale" "Nega accesso tramite Servizi Desktop remoto" (e qualsiasi altro applicabile).

Tieni presente che potrei mancare alcune cose qui perché ho provato solo questo per impedire agli utenti di visualizzare gli account di servizio nella schermata di accesso.

    
risposta data 20.09.2018 - 08:42
fonte

Leggi altre domande sui tag