locked
Error code 0x80090304 on queries requiring AD logins RRS feed

  • Question

  • My config:
    Ubuntu Server 16.04.5 LTS x64
    SQLServer 2017 on Linux (just updated to CU13 - 14.0.3048.1)
    SSMS 17.9.1

    When I run the following query:

    EXECUTE AS LOGIN='DOMAINNAME\domain.user'
    GO

    I get this error message:

    Msg 15404, Level 16, State 22, Line 1
    Could not obtain information about Windows NT group/user 'DOMAINNAME\domain.user', error code 0x80090304.

    The error is thrown both if logged in with sa and with DOMAINNAME\domain.user user (which is an admin too).

    I've already followed the troubleshooting documentation and checked everything, multiple times: DNS, hosts, service account, SPN, wbinfo -u, wbinfo -g, ...
    SQLServer log contains nothing relevant (in fact it reports nothing at all).

    Anyone can help me understand what's wrong on my side?
    Is there a way to increase the (now useless) log verbosity in /var/opt/mssql/log/errorlog ?



    • Edited by nicorac Wednesday, December 19, 2018 8:19 AM
    Wednesday, December 19, 2018 8:08 AM

All replies

  • Using the the old Error Lookup utility I find that the error code means "The Local Security Authority cannot be contacted". So it seems that you have problems in contacting the AD.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Wednesday, December 19, 2018 10:51 PM
  • Using the the old Error Lookup utility I find that the error code means "The Local Security Authority cannot be contacted". So it seems that you have problems in contacting the AD.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Could be, but AD logins work and users are able to authenticate with their AD credentials (i.e. with Access ODBC linked tables).

    Only administrative commands don't work.

    Another weird thing I've seen is this: if logged in with my administrative AD account I can only run one "administrative" action (i.e. create a table, add field, delete user, ...). After that action I get the same error but after reconnecting, i can see that the action was completed successfully.
    No issues at all if I log in with 'sa'.

    Thursday, December 20, 2018 9:26 AM
  • Another weird thing I've seen is this: if logged in with my administrative AD account I can only run one "administrative" action (i.e. create a table, add field, delete user, ...). After that action I get the same error but after reconnecting, i can see that the action was completed successfully.

    No issues at all if I log in with 'sa'.

    That's sort of interesting. I've never heard of that before. But maybe SQL Server reaches out to the AD to see which groups you are member of? I take it that your administrative account is not member of sysadmin itself, but has this membership through membership in an AD group?

    Note that it is not yourself that have issues with reaching the AD, but SQL Server and its service account.

    When doing a plain login, SQL Server may not have to talk to the AD directly, as it gets all token directly. (I will have to admit that I'm guessing a little bit here.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se


    • Edited by Erland SommarskogMVP Thursday, December 20, 2018 10:57 PM Posted too early.
    • Proposed as answer by Bob_FT Sunday, December 23, 2018 4:10 PM
    Thursday, December 20, 2018 10:56 PM
  • My AD user 'DOMAINNAME\domain.user' is set as 'sysadmin' on srvsqlserver.

    Will try to restart from scratch, deleting all accounts on AD and keytabs on Linux server...

    The worst thing is that I can't find a way to increase log verbosity up to what I'm used to in Linux.
    /var/opt/mssql/log/errorlog is completely useless and, in this case, it reports nothing at all!

    I'll throw the question again: is there a way to increase log verbosity?


    • Edited by nicorac Wednesday, December 26, 2018 10:09 AM typo
    Friday, December 21, 2018 7:36 AM
  • Nope.
    Sunday, December 23, 2018 4:10 PM