Creazione del servizio Python per eseguire query sugli attributi AD
Sto integrando il nostro AD con i servizi Web che eseguono Python su Linux usando Python-LDAP su SASL (DIGEST-MD5) per interrogare gli attributi utente di AD 2012 (divisione, dipartimento, estensione del telefono, e-mail, ecc.). Dopo aver elaborato i nodi specifici del mio servizio su un AD 2003, ho iniziato a riscontrare un errore SPN sul nostro nuovo AD 2012, che digest-uri non corrispondeva a nessun SPN sul server. Ho fatto un riferimento incrociato all'elenco SPN per entrambi i server e contengono analoghi identici tra loro.
L'errore: digest-uri non corrisponde a nessun SPN LDAP registrato per questo server
La correzione?
Questo è stato risolto eseguendo:
setspn -A ldap/<Domain_Name> <Computer_Name>
Si noti che la creazione di un account di servizio non ha corretto l'errore SPN anche quando è stato eseguito il comando seguente:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
simple_bind_s () non ha bisogno di SPN, sasl_interactive_bind_s () ha bisogno di SPN
Solo l'aggiunta dell'SPN all'elenco SPN del computer locale ha funzionato per il mio servizio Python-LDAP usando sasl_interactive_bind_s (). Dovrei anche notare che il passaggio SPN può essere ignorato se uso simple_bind_s () ma questo metodo invia credenziali in chiaro che è inaccettabile.
Tuttavia ho notato che il record rimane nell'elenco SPN solo per circa un minuto prima di scomparire? Non ci sono errori quando eseguo il comando setspn, i registri degli eventi sono completamente vuoti, non ci sono duplicati da nessuna parte, controllati con la ricerca a livello di foresta -F sulla base dn e niente. Ho aggiunto e provato a aggiungere nuovamente e rimosso e spostato l'SPN da un oggetto all'altro per verificare che non si nascondesse da nessuna parte, ma il secondo aggiungo l'oggetto ovunque e quindi provo a aggiungere nuovamente mi avvisa di un duplicato. Quindi sono molto fiducioso che non ci sia un duplicato nascosto da qualche parte.
L'hack
Per ora ho un'attività pianificata che esegue nuovamente il comando per mantenere il record nell'elenco in modo che il mio servizio funzionerà appropriatamente chiamato "SPN Hack"
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
fino a quando non riesco a scoprire perché l'SPN viene rimosso dall'elenco.
Non sono l'amministratore principale di questo particolare annuncio pubblicitario, l'amministratore potrebbe avere un servizio in esecuzione che sincronizza l'SPN da un altro servizio nell'AD e non esserne consapevole? Il mio titolo è Web Developer, non come una scusa ma per spiegare la mia ignoranza in materia di Active Directory. Mi è stato detto di rendere l'AD il DB utente principale e ho letto molto, ma non riesco a trovare da nessuna parte dove le persone hanno un problema con l'SPN che viene "sovrascritto" o "ripulito" periodicamente e nessuno dei gli amministratori hanno molta familiarità con SPN al di fuori delle voci di SQL Server.
Perché ho bisogno dell'hack?
Finora il mio hack non sembra aver causato problemi a nessun utente o servizio e non abbia generato alcun errore, quindi l'amministratore dice che lo lascerà semplicemente funzionare e continuerò a cercare. Ma poi mi trovo nella situazione precaria di scrivere un servizio la cui implementazione è basata, essenzialmente un cron hack / brividi ... Quindi, qualsiasi aiuto sarebbe apprezzato.
Aggiornare
Dopo una conversazione con l'amministratore di sistema ha concordato che la creazione di un servizio in cima a un hack non è una soluzione, quindi mi ha dato il permesso di creare un servizio locale con crittografia endpoint che posso usare per i miei scopi, il risultato è lo stesso . Terrò d'occhio ciò che sta causando la cancellazione dell'SPN. I bind locali non sono un problema con Python-LDAP e il servizio locale è già attivo e funzionante dopo solo un'ora circa. È un peccato che essenzialmente stia avvolgendo le funzionalità integrate in LDAP ma facciamo quello che dobbiamo fare.
