Perché suser_name () non rifletterebbe una modifica del nome dell'account AD?

Uno dei nomi dei nostri utenti è stato modificato legalmente, quindi abbiamo modificato il loro nome utente di Active Directory in modo che corrisponda, da dominio \ vecchio a dominio \ nuovo. Tuttavia, quando suser_sname () viene chiamato da questo utente in una procedura memorizzata, restituisce il vecchio nome, non quello nuovo.

Google mi ha portato a 946358 KB, il che suggerisce che il loro nome viene memorizzato nella cache sul server e non aggiornato, presumibilmente perché suser_name () sta chiamando LsaLookupSids. Tuttavia, la soluzione alternativa in quell'articolo comporta il riavvio del server e, anche se fosse, mi piacerebbe ancora capire il problema.

Se cambio il mio contesto nel loro, il nome corretto ritorna:

EXECUTE AS LOGIN = 'domain\newname'
GO
SELECT suser_name()   --returns 'domain\newname'

... Avrei supposto che questo avrebbe anche chiamato LsaLookupSids, e quindi avrebbe restituito il nome errato. Sembra probabile che non capisca davvero i meccanismi al lavoro qui.

Alcune osservazioni che potrebbero interessare:

Questo utente non ha un accesso esplicito sul server. Ma fanno parte di un gruppo AD che lo fa. Il nome modificato (domain \ newname) appare nel set di risultati per exec xp_logininfo 'domain\ADGroupName', 'members'; dominio \ vecchio nome no.
L'utente sta chiamando suser_name () da una procedura memorizzata, chiamata da una query passthrough in un MDB di Access 2003.
Abbiamo cambiato molti nomi di account degli utenti in passato, ma abbiamo riscontrato questo problema solo nell'ultima settimana (due modifiche sono state apportate nell'ultima settimana, entrambe sembrano mostrare il problema).
Il server esegue Sql Server 2008 SP3 x64 su Windows 2008 R2 Datacenter edition.

Cosa sta succedendo? Come DBA, cosa potrei fare o dove potrei cercare di risolverlo?

— Warrior Bob
fonte

Il servizio MSSQLSERVER (o qualunque sia il nome dell'istanza) sta accedendo come Sistema locale o un vero Login? Il valore potrebbe essere memorizzato nella cache del registro dell'account che esegue la ricerca. Nel tuo caso, hai effettuato l'accesso e hai effettuato la richiesta. Sto pensando che forse se si utilizza un account normale per eseguire SQL Server (come si dovrebbe), quindi forse accedere a SQL Server come login "SQL Server", quindi eseguire il tuo EXECUTE ASe SELECT SUSER_NAME()testare. Inoltre, hai provato SUSER_SNAME()e una delle altre 100 varianti?

— Solomon Rutzky,

Prova a creare un accesso all'istanza utilizzando il nuovo nome. Ciò non avrà alcun effetto sulle loro autorizzazioni. Esegui SUSER_SNAME(), dovrebbe essere riparato a quel punto. Puoi quindi provare a eliminare l'accesso e vedere se mantiene il nuovo nome.

— Kenneth Fisher,

@srutzky È un'istanza MSSQLSERVER predefinita in esecuzione con un account di dominio. Sfortunatamente non ho la password per accedere con essa. Non ho ancora provato suser_sname () come utente, credo che sia lo stesso di suser_name () se non viene fornito alcun argomento. Vale la pena provare, grazie!

— Warrior Bob

SQL Server corrisponde a tutti gli account dal SID, sia SQL che di dominio. Poiché i SID di dominio provengono da Active Directory, la modifica del nome non modifica il SID. Se è stato memorizzato nella cache, verrà restituito il vecchio nome. Se esiste già un accesso, il nome dell'account verrà restituito indipendentemente dal fatto che sia sempre lo stesso nome, purché i SID corrispondano. Questo è lo stesso per gli utenti di database.

— Sean Gallardy,

Potresti provare a eseguire ipconfig /flushdnse ipconfig /registerdnsda una riga di comando per vedere se questo risolve il problema.

— RLF,

Questo potrebbe essere correlato alla memorizzazione nella cache con Kerberos? (solo un'ipotesi potrebbe non essere correlata) http://blogs.technet.com/b/tspring/archive/2014/06/23/viewing-and-purging-cached-kerberos-tickets.aspx

— Normoe
fonte

Non posso dire con certezza che questo è il problema, ma credo che questo o qualcosa del genere lo sia. Il riavvio del server (che è avvenuto per motivi separati) sembra averlo chiarito, almeno per questo caso. Non è chiaro se tornerà di nuovo.

— Warrior Bob,

È un buon suggerimento, avrei dovuto pensarci! :-) Questo è quello che abbiamo fatto prima per chiarire i problemi di Kerberos nella cache. Sono contento che tu abbia avuto successo!

— Normoe,