Procedura consigliata per collegare il server disponibile al pubblico a LDAP / Active Directory interni?

Question

Procedura consigliata per collegare il server disponibile al pubblico a LDAP / Active Directory interni?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Abbiamo un sito web pubblico. Il sito contiene anche la rete intranet (sebbene nessuno dei dati presenti nelle pagine della intranet sia terribilmente segreto). Gli utenti devono accedere al sito Web utilizzando le proprie credenziali di Active Directory per visualizzare le pagine della intranet.

Il server Web si trova nella DMZ, ma la porta per LDAPS è aperta attraverso il firewall dal sito Web al controller di dominio.

(Il diagramma sopra è semplificato. In realtà c'è un altro firewall tra Internet e il sito web, ma sto divagando.)

Tuttavia, non mi sento particolarmente a mio agio con questa configurazione. Se una parte dovesse compromettere il server Web, la parte avrà una limitata capacità di vedere il controller di dominio attraverso la porta LDAPS. Inoltre, non sono sicuro che ci sia un buon modo per prevenire gli attacchi di forza bruta in questo scenario.

Esiste una configurazione più sicura per raggiungere lo stesso obiettivo?

Non ho nulla a che fare direttamente con esso, ma stiamo usando Azure AD per Office 365 ed è sincronizzato con il nostro annuncio locale. Sarebbe più sicuro usare Azure AD per l'autenticazione? La mia comprensione è che SSO attraverso Azure costa altri dollari, però.

sso webserver ldap dmz

posta JasonF 29.12.2017 - 07:39

fonte

3 risposte

Leggi altre domande sui tag sso webserver ldap dmz

In che modo ASLR protegge i punti di ingresso di libc? Perché l'installazione Ubuntu di casa dice che il mio hostname scelto si risolve in un IP esterno?

score 1 · Answer 1

Non mi sembra che questo produca una superficie di attacco particolarmente pericolosa - A condizione che i tuoi account AD siano sufficientemente sicuri che le loro password non possono essere forzate brute e che il tuo server LDAP sia correttamente protetto e corretto. Se è vero che un compromesso del server Web aprirebbe il tuo server LDAP agli attacchi, non c'è molto che tu possa fare per mitigarlo.

Ho considerato che se il tuo server web viene compromesso, potrebbe essere utile avere un proxy tra il tuo server web e il server LDAP, ma questo ti dà un altro server da aggiornare e correggere, altrimenti questo sarà solo compromesso e usato per attaccare invece il server LDAP. Ovviamente, non è una cosa certa e richiede un'altra serie di attacchi per entrare nella stessa posizione della situazione senza il server web, ma può fornire una difesa extra in profondità.

score 0 · Answer 2

Il libro, Criteri di gruppo: Fondamenti, Sicurezza e Desktop gestito, Terza edizione ha un'appendice E che copre l'uso di Microsoft Intune per l'applicazione di patch esterne in combinazione con PolicyPak Cloud per le impostazioni dei criteri di gruppo quando remoto o unito al dominio (ad es. , VPN) - o remoto e non appartenente al dominio.

score 0 · Answer 3

However, I don't feel terribly comfortable with this setup.

E IMO hai ragione con i tuoi sentimenti.

Esempio: se sei amministratore di dominio attivato blocco account dopo ripetuti errori di accesso, un utente malintenzionato esterno può avviare un attacco denial-of-service nell'intero dominio che indovina i nomi utente.

Potresti attenuarlo limitando gli accessi non riusciti nella tua applicazione web. Ma devi implementarlo in modo affidabile in ogni applicazione web utilizzando questo tipo di accesso.

Un'altra soluzione potrebbe essere l'autenticazione a due fattori utilizzata per controllare l'OTP prima di controllare realmente la password dell'utente.

Un'altra cosa da considerare con i tuoi amministratori di dominio: A volte aggiornano la propria infrastruttura di controller di dominio (DC) installando nuovi controller di dominio con la versione di Windows più recente in esecuzione su diversi indirizzi IP ma che servono lo stesso dominio. Questo non è un problema nel mondo Windows perché i DC sono annunciati tramite DNS SRV RR. Ma probabilmente dovrai modificare le regole del tuo firewall.

Inoltre suggerisco di installare un proxy a livello di applicazione LDAP basato su OpenLDAP 's back-ldap perché OpenLDAP ha una validazione dell'input piuttosto rigida su PDU LDAP. Con una tale configurazione puoi anche limitare l'accesso LDAP a es. un determinato gruppo AD che attenua il rischio per il resto del dominio.

Per quanto riguarda la crittografia dei trasporti: Sì, usa TLS ovunque!

Per quanto riguarda Web-SSO: Sì, è una soluzione praticabile perché con la maggior parte dei protocolli SSO il browser dell'utente viene reindirizzato a un provider di identità, i messaggi SSO sono firmati e quindi non è necessario accedere direttamente a una gestione utente dalla tua app. Devi immergerti nei protocolli un po 'per capirlo.