RE: - Microsoft SQL Server Linux GSSAPI Questions / Issues

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: - Microsoft SQL Server Linux GSSAPI Questions / Issues

Robert Dorr
We have encountered a few issues and we are looking for some insights.
Building gssapi and krb5


We pulled the MIT and github version of the krb5 project. In the MIT version we can execute configure in the src directory and then make and build as expected.
The github version states it is a replica of the MIT version.  We run autoconf and try to build and it always reports include/autoconf.in<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fautoconf.in&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=ce3NmShCdmQVGDpTWzP97ml8%2F6XzaioRBnEj7XTlg98%3D&reserved=0> is missing.   If we copy from the MIT version we can then build.   Are we missing a step?
When you build for non-optimized debugging are what flags do you recommend?    CFLAGS=-ggdb -DDEBUG ?

Caching Issues

We are seeing a strange issue with the krb5 caching that we hope you can shed some light on.
Scenario  (Some trace information at end of e-mail)
Ubuntu 16.04 VM  (Machine name MACHINE)
Joined to realm: DOMAIN.XYZ.XYZ  (Windows AD, running in VM on same physical host)
Everything running as root
kdestroy to remove root krb5cc_0 cache file
klist – shows no file

gss_acquire_cred_from for machine (MACHINE$) – succeeds and creates krb5cc_0 – principal is MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>
call gss_aquire_cred_with_password for ([hidden email]<mailto:[hidden email]>) – fails with error that cache is not the correct principal
If we kdestroy the krbcc_0 and execute the gss_acquire in reverse order the principal for krb5cc_0 is [hidden email]<mailto:[hidden email]> and both calls succeed.
If we force the cache to be KEYRING:persistant we can kdestroy and run in any order and the api calls succeed.
Is there a recommended cache for best security and if so how can it be forced?

UPC Failures

We notice that enabling KRB5_TRACE we often see the following. Is there a way to avoid the UPN call in order to improve performance?
[20681] 1516383737.459171: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[20681] 1516383737.459172: Request or response is too big for UDP; retrying with TCP





gss_acquire_cred_from – Successful trace



[20681] 1516383737.459128: Retrieving MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from FILE:/var/opt/mssql/secrets/mssql.keytab (vno 0, enctype 0) with result: 0/Success

[20681] 1516383737.459129: Retrieving MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from FILE:/var/opt/mssql/secrets/mssql.keytab (vno 0, enctype 0) with result: 0/Success

[20681] 1516383737.459130: Getting initial credentials for MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>

pkinit_init_plg_crypto: initializing openssl crypto context at 0x7fdaf2d4e0e0

pkinit_client_plugin_init: returning plgctx at 0x7fdaf2c959c0

pkinit_init_req_crypto: returning ctx at 0x7fdaf2d501b0

pkinit_init_identity_crypto: returning ctx at 0x7fdaf2ce9000

pkinit_client_req_init: returning reqctx at 0x7fdaf2cc21f0

[20681] 1516383737.459131: Looked up etypes in keytab: rc4-hmac, aes128-cts, aes256-cts, rc4-hmac, aes128-cts, aes256-cts

[20681] 1516383737.459133: Sending unauthenticated request

[20681] 1516383737.459134: Sending request (188 bytes) to DOMAIN.XYZ.XYZ

get_plugin_data_sym(service_locator)

[20681] 1516383737.459135: Resolving hostname USERDC.DOMAIN.XYZ.XYZ

[20681] 1516383737.459136: Sending initial UDP request to dgram 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

[20681] 1516383737.459137: Received answer (224 bytes) from dgram 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

get_plugin_data_sym(service_locator)

[20681] 1516383737.459138: Sending DNS URI query for _kerberos.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459139: No URI records found

[20681] 1516383737.459140: Sending DNS SRV query for _kerberos-master._udp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459141: Sending DNS SRV query for _kerberos-master._tcp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459142: No SRV records found

[20681] 1516383737.459143: Response was not from master KDC

[20681] 1516383737.459144: Received error from KDC: -1765328359/Additional pre-authentication required

preauth data types before sorting: 19 2 16 15

preauth data types after sorting: 16 15 19 2

[20681] 1516383737.459147: Preauthenticating using KDC method data

[20681] 1516383737.459148: Processing preauth types: 16, 15, 19, 2

[20681] 1516383737.459149: Selected etype info: etype aes256-cts, salt "DOMAIN.XYZ.XYZhostMACHINE.DOMAIN.XYZ.XYZ", params ""

pkinit_client_profile 0x7fdaf2cf5400 0x7fdaf2c959c0 0x7fdaf2cc21f0 0x7fdaf2cec528

pkinit_identity_initialize: 0x7fdaf2cf5400 0x7fdaf2cc4eb0 0x7fdaf2ce9000

pkinit_identity_initialize: no user identity options specified

[20681] 1516383737.459150: PKINIT client has no configured identity; giving up

pkinit_identity_initialize returned -1765328174 (Generic preauthentication failure)

pkinit_client_prep_questions: not asking responder question

pkinit_client_prep_questions returning 0

pkinit_client_prep_questions: no questions to ask

pkinit_client_prep_questions returning 0

pkinit_client_process 0x7fdaf2cf5400 0x7fdaf2c959c0 0x7fdaf2cc21f0 0x7fdaf2d0c000

processing KRB5_PADATA_PK_AS_REQ

pkinit_client_profile 0x7fdaf2cf5400 0x7fdaf2c959c0 0x7fdaf2cc21f0 0x7fdaf2cec528

pkinit_identity_prompt: 0x7fdaf2cf5400 0x7fdaf2cc4eb0 0x7fdaf2ce9000

[20681] 1516383737.459151: PKINIT client has no configured identity; giving up

pkinit_identity_prompt returned 22 (Invalid argument)

[20681] 1516383737.459152: Preauth module pkinit (16) (real) returned: 22/Invalid argument

pkinit_client_process 0x7fdaf2cf5400 0x7fdaf2c959c0 0x7fdaf2cc21f0 0x7fdaf2d0c000

[20681] 1516383737.459153: PKINIT client ignoring draft 9 offer from RFC 4556 KDC

[20681] 1516383737.459154: Preauth module pkinit (15) (real) returned: -1765328360/Preauthentication failed

[20681] 1516383737.459155: Retrieving MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from FILE:/var/opt/mssql/secrets/mssql.keytab (vno 0, enctype aes256-cts) with result: 0/Success

[20681] 1516383737.459156: AS key obtained for encrypted timestamp: aes256-cts/BA29

[20681] 1516383737.459158: Encrypted timestamp (for 1516383737.782772): plain 301AA011180F32303138303131393137343231375AA10502030BF1B4, encrypted 4357C375F225BCEFB7025947F75031F76394B2621ABD8F0849500A7F31900B3E34581CB90B34541EEA43D51F890264AC751AD3BC6C409179

[20681] 1516383737.459159: Preauth module encrypted_timestamp (2) (real) returned: 0/Success

[20681] 1516383737.459160: Produced preauth for next request: 2

[20681] 1516383737.459161: Sending request (268 bytes) to DOMAIN.XYZ.XYZ

get_plugin_data_sym(service_locator)

[20681] 1516383737.459162: Resolving hostname USERDC.DOMAIN.XYZ.XYZ

[20681] 1516383737.459163: Sending initial UDP request to dgram 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

[20681] 1516383737.459164: Received answer (104 bytes) from dgram 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

get_plugin_data_sym(service_locator)

[20681] 1516383737.459165: Sending DNS URI query for _kerberos.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459166: No URI records found

[20681] 1516383737.459167: Sending DNS SRV query for _kerberos-master._udp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459168: Sending DNS SRV query for _kerberos-master._tcp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459169: No SRV records found

[20681] 1516383737.459170: Response was not from master KDC

[20681] 1516383737.459171: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP

[20681] 1516383737.459172: Request or response is too big for UDP; retrying with TCP

[20681] 1516383737.459173: Sending request (268 bytes) to DOMAIN.XYZ.XYZ (tcp only)

get_plugin_data_sym(service_locator)

[20681] 1516383737.459174: Resolving hostname USERDC.DOMAIN.XYZ.XYZ

[20681] 1516383737.459175: Initiating TCP connection to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

[20681] 1516383737.459176: Sending TCP request to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

[20681] 1516383737.459177: Received answer (1607 bytes) from stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462269832&sdata=9%2BJBCdP4kPjsRzu2EyiI9zAx84u2JJz0s7D8BU6j72Y%3D&reserved=0>

[20681] 1516383737.459178: Terminating TCP connection to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462279836&sdata=xSTbrWLRBquOwfdifRK2%2BWxcZxorAReQ3kW03uPHdMY%3D&reserved=0>

get_plugin_data_sym(service_locator)

[20681] 1516383737.459179: Sending DNS URI query for _kerberos.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459180: No URI records found

[20681] 1516383737.459181: Sending DNS SRV query for _kerberos-master._tcp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459182: No SRV records found

[20681] 1516383737.459183: Response was not from master KDC

preauth data types before sorting: 19

preauth data types after sorting: 19

[20681] 1516383737.459184: Processing preauth types: 19

[20681] 1516383737.459185: Selected etype info: etype aes256-cts, salt "DOMAIN.XYZ.XYZhostMACHINE.DOMAIN.XYZ.XYZ", params ""

[20681] 1516383737.459186: Produced preauth for next request: (empty)

[20681] 1516383737.459187: AS key determined by preauth: aes256-cts/BA29

[20681] 1516383737.459188: Decrypted AS reply; session key is: aes256-cts/CF2F

[20681] 1516383737.459189: FAST negotiation: unavailable

[20681] 1516383737.459190: Initializing FILE:/tmp/krb5cc_0 with default princ MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>

[20681] 1516383737.459191: Storing MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> -> krbtgt/[hidden email]<mailto:krbtgt/[hidden email]> in FILE:/tmp/krb5cc_0

[20681] 1516383737.459192: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[hidden email]<mailto:krbtgt/[hidden email]>: pa_type: 2

[20681] 1516383737.459193: Storing MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> -> krb5_ccache_conf_data/pa_type/krbtgt\/DOMAIN.XYZ.XYZ\@DOMAIN.XYZ.XYZ@X-CACHECONF: in FILE:/tmp/krb5cc_0

pkinit_client_req_fini: received reqctx at 0x7fdaf2cc21f0

pkinit_fini_req_crypto: freeing ctx at 0x7fdaf2d501b0

pkinit_fini_identity_crypto: freeing ctx at 0x7fdaf2ce9000

[20681] 1516383737.459194: Storing config in FILE:/tmp/krb5cc_0 for : refresh_time: 1516401737

[20681] 1516383737.459195: Storing MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in FILE:/tmp/krb5cc_0

pkinit_client_plugin_fini: got plgctx at 0x7fdaf2c959c0

pkinit_fini_plg_crypto: freeing context at 0x7fdaf2d4e0e0

[20681] 1516383737.459199: Getting credentials [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> using ccache FILE:/tmp/krb5cc_0

[20681] 1516383737.459200: Retrieving [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_0)

[20681] 1516383737.459201: Getting credentials MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> -> krbtgt/[hidden email]<mailto:krbtgt/[hidden email]> using ccache FILE:/tmp/krb5cc_0

[20681] 1516383737.459202: Retrieving MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> -> krbtgt/[hidden email]<mailto:krbtgt/[hidden email]> from FILE:/tmp/krb5cc_0 with result: 0/Success

[20681] 1516383737.459203: Get cred via TGT krbtgt/[hidden email]<mailto:krbtgt/[hidden email]> after requesting MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> (canonicalize on)

[20681] 1516383737.459204: Generated subkey for TGS request: aes256-cts/425D

[20681] 1516383737.459205: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts

[20681] 1516383737.459207: Encoding request body and padata into FAST request

[20681] 1516383737.459208: Sending request (2129 bytes) to DOMAIN.XYZ.XYZ

get_plugin_data_sym(service_locator)

[20681] 1516383737.459209: Resolving hostname USERDC.DOMAIN.XYZ.XYZ

[20681] 1516383737.459210: Initiating TCP connection to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462279836&sdata=xSTbrWLRBquOwfdifRK2%2BWxcZxorAReQ3kW03uPHdMY%3D&reserved=0>

[20681] 1516383737.459211: Sending TCP request to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462279836&sdata=xSTbrWLRBquOwfdifRK2%2BWxcZxorAReQ3kW03uPHdMY%3D&reserved=0>

[20681] 1516383737.459212: Received answer (1810 bytes) from stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462279836&sdata=xSTbrWLRBquOwfdifRK2%2BWxcZxorAReQ3kW03uPHdMY%3D&reserved=0>

[20681] 1516383737.459213: Terminating TCP connection to stream 999.999.999.999:88<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.135.10.178%3A88&data=02%7C01%7Crdorr%40microsoft.com%7C9dc37f31467c450f92ac08d560a5fff0%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C1%7C636521188462279836&sdata=xSTbrWLRBquOwfdifRK2%2BWxcZxorAReQ3kW03uPHdMY%3D&reserved=0>

get_plugin_data_sym(service_locator)

[20681] 1516383737.459214: Sending DNS URI query for _kerberos.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459215: No URI records found

[20681] 1516383737.459216: Sending DNS SRV query for _kerberos-master._udp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459217: Sending DNS SRV query for _kerberos-master._tcp.DOMAIN.XYZ.XYZ.

[20681] 1516383737.459218: No SRV records found

[20681] 1516383737.459219: Response was not from master KDC

[20681] 1516383737.459220: Decoding FAST response

[20681] 1516383737.459221: FAST reply key: aes256-cts/8208

[20681] 1516383737.459222: TGS reply is for [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> with session key aes256-cts/4152

[20681] 1516383737.459223: Got cred; 0/Success

[20681] 1516383737.459224: Resolving unique ccache of type MEMORY

[20681] 1516383737.459225: Initializing MEMORY:1Et9YKF with default princ [hidden email]<mailto:[hidden email]>

[20681] 1516383737.459226: Storing [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> in MEMORY:1Et9YKF

[20681] 1516383737.459230: Getting credentials [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> using ccache MEMORY:1Et9YKF

[20681] 1516383737.459231: Retrieving [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from MEMORY:1Et9YKF with result: 0/Success

[20681] 1516383737.459233: Creating authenticator for [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>, seqnum 81267597, subkey aes256-cts/0CB9, session key aes256-cts/4152

[20681] 1516383737.459238: Retrieving MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL> from FILE:/var/opt/mssql/secrets/mssql.keytab (vno 8, enctype aes256-cts) with result: 0/Success

[20681] 1516383737.459239: Decrypted AP-REQ with specified server principal MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>: aes256-cts/BA29

[20681] 1516383737.459240: AP-REQ ticket: [hidden email]<mailto:[hidden email]> -> MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>, session key aes256-cts/4152

get_plugin_data_sym(authdata_client_0)

init module "mspac", ad_type 128, flags 00000002

init module "constrained-delegation", ad_type 512, flags 00000008

init module "authentication-indicators", ad_type 97, flags 00000020

[20681] 1516383737.459241: Negotiated enctype based on authenticator: aes256-cts

[20681] 1516383737.459242: Authenticator contains subkey: aes256-cts/0CB9

get_plugin_data_sym(authdata_client_0)

init module "mspac", ad_type 128, flags 00000002

init module "constrained-delegation", ad_type 512, flags 00000008

init module "authentication-indicators", ad_type 97, flags 00000020

[20681] 1516383737.459245: Destroying ccache MEMORY:1Et9YKF

get_plugin_data_sym(authdata_client_0)

init module "mspac", ad_type 128, flags 00000002

init module "constrained-delegation", ad_type 512, flags 00000008

init module "authentication-indicators", ad_type 97, flags 00000020

get_plugin_data_sym(authdata_client_0)

init module "mspac", ad_type 128, flags 00000002

init module "constrained-delegation", ad_type 512, flags 00000008

init module "authentication-indicators", ad_type 97, flags 00000020





------------------------------------------------------------------------

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: MACHINE$@DOMAIN.XYZ.XYZ<mailto:RDORRLINUXB$@LEWISVILLE.LOCAL>



Valid starting       Expires              Service principal

01/19/2018 11:42:17  01/19/2018 21:42:17  krbtgt/[hidden email]<mailto:krbtgt/[hidden email]>

        renew until 01/20/2018 11:42:17



--------------------------------------------------------------------

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: [hidden email]<mailto:[hidden email]>



Valid starting       Expires              Service principal

01/19/2018 11:45:49  01/19/2018 21:45:49  krbtgt/[hidden email]<mailto:krbtgt/[hidden email]>

        renew until 01/20/2018 11:45:45



Bob Dorr - [hidden email]<mailto:[hidden email]>
Principal Software Engineer SQL Server

Manager: [hidden email]<mailto:[hidden email]> or [hidden email]<mailto:[hidden email]>




--

Thank you,
Dmitri Pal

Engineering Director, Identity Management and Platform Security
Red Hat, Inc.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: - Microsoft SQL Server Linux GSSAPI Questions / Issues

Greg Hudson
On 01/21/2018 02:22 PM, Robert Dorr wrote:
> We pulled the MIT and github version of the krb5 project. In the MIT version we can execute configure in the src directory and then make and build as expected.
> The github version states it is a replica of the MIT version.

The github krb5/krb5 repository is a mirror of the authoritative MIT
krb5 git repository, which is not publically available.  The tarfile
distributions are created from the authoritative git repository, but are
not simply checkouts; they have the autoconf-generated files, a build of
the documentation, and

> We run autoconf and try to build and it always reports [...]

You want to run "autoreconf" instead of "autoconf".

> Caching Issues

> gss_acquire_cred_from for machine (MACHINE$) – succeeds and creates krb5cc_0 – principal is MACHINE$@DOMAIN.XYZ.XYZ
> call gss_aquire_cred_with_password for ([hidden email]) – fails with error that cache is not the correct principal
> If we kdestroy the krbcc_0 and execute the gss_acquire in reverse order the principal for krb5cc_0 is [hidden email] and both calls succeed.
> If we force the cache to be KEYRING:persistant we can kdestroy and run in any order and the api calls succeed.
> Is there a recommended cache for best security and if so how can it be forced?

This answer may be a little scattered, as I can't tell what the desired
behavior is for your use case.

If you want to cache credentials for two different client principals in
default cache, the default cache needs to use a collection-enabled cache
type.  KEYRING and DIR are collection-enabled; FILE is not.

If you are using gss_acquire_cred_from() with a "keytab" key, you could
also specify a "ccache" key to control where the obtained credentials
will be cached.  This could be a MEMORY cache or a FILE cache at a
dedicated location.

gss_acquire_cred_from() unfortunately has different behavior depending
on the version.  It originated in Solaris Kerberos, where it stores the
obtained credentials in a unique memory cache.  It is then up to the
caller to use gss_store_cred() or gss_store_cred_into() to put the
credentials into an externally visible cache, if that is desired.  MIT
krb5 1.14 and later have the same behavior.  But prior versions of MIT
krb5 (including 1.13, which is what Ubuntu 16.04 ships with)
automatically store the obtained credentials in the default cache.

If you are using gss_acquire_cred_from() and need to work with older
versions of MIT krb5, I think the best option is to use
gss_krb5_ccache_name() before the call to set the default ccache to a
memory cache, and then again after the call to set it back to the
previous value for the thread.

> UPC Failures
>
> We notice that enabling KRB5_TRACE we often see the following. Is there a way to avoid the UPN call in order to improve performance?
> [20681] 1516383737.459171: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
> [20681] 1516383737.459172: Request or response is too big for UDP; retrying with TCP

In krb5.conf, set:

    [libdefaults]
        udp_preference_limit = 0
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: - Microsoft SQL Server Linux GSSAPI Questions / Issues

Robert Dorr
This is great information and extremely helpful.  Thank you for the quick response.


-----Original Message-----
From: Greg Hudson [mailto:[hidden email]]
Sent: Sunday, January 21, 2018 3:27 PM
To: Robert Dorr <[hidden email]>; [hidden email]
Cc: Scott Konersmann <[hidden email]>; Mitchell Sternke <[hidden email]>; Dylan Gray <[hidden email]>
Subject: Re: - Microsoft SQL Server Linux GSSAPI Questions / Issues

On 01/21/2018 02:22 PM, Robert Dorr wrote:
> We pulled the MIT and github version of the krb5 project. In the MIT version we can execute configure in the src directory and then make and build as expected.
> The github version states it is a replica of the MIT version.

The github krb5/krb5 repository is a mirror of the authoritative MIT
krb5 git repository, which is not publically available.  The tarfile distributions are created from the authoritative git repository, but are not simply checkouts; they have the autoconf-generated files, a build of the documentation, and

> We run autoconf and try to build and it always reports [...]

You want to run "autoreconf" instead of "autoconf".

> Caching Issues

> gss_acquire_cred_from for machine (MACHINE$) – succeeds and creates
> krb5cc_0 – principal is MACHINE$@DOMAIN.XYZ.XYZ call
> gss_aquire_cred_with_password for ([hidden email]) – fails with error that cache is not the correct principal If we kdestroy the krbcc_0 and execute the gss_acquire in reverse order the principal for krb5cc_0 is [hidden email] and both calls succeed.
> If we force the cache to be KEYRING:persistant we can kdestroy and run in any order and the api calls succeed.
> Is there a recommended cache for best security and if so how can it be forced?

This answer may be a little scattered, as I can't tell what the desired behavior is for your use case.

If you want to cache credentials for two different client principals in default cache, the default cache needs to use a collection-enabled cache type.  KEYRING and DIR are collection-enabled; FILE is not.

If you are using gss_acquire_cred_from() with a "keytab" key, you could also specify a "ccache" key to control where the obtained credentials will be cached.  This could be a MEMORY cache or a FILE cache at a dedicated location.

gss_acquire_cred_from() unfortunately has different behavior depending on the version.  It originated in Solaris Kerberos, where it stores the obtained credentials in a unique memory cache.  It is then up to the caller to use gss_store_cred() or gss_store_cred_into() to put the credentials into an externally visible cache, if that is desired.  MIT
krb5 1.14 and later have the same behavior.  But prior versions of MIT
krb5 (including 1.13, which is what Ubuntu 16.04 ships with) automatically store the obtained credentials in the default cache.

If you are using gss_acquire_cred_from() and need to work with older versions of MIT krb5, I think the best option is to use
gss_krb5_ccache_name() before the call to set the default ccache to a memory cache, and then again after the call to set it back to the previous value for the thread.

> UPC Failures
>
> We notice that enabling KRB5_TRACE we often see the following. Is there a way to avoid the UPN call in order to improve performance?
> [20681] 1516383737.459171: Received error from KDC:
> -1765328332/Response too big for UDP, retry with TCP [20681]
> 1516383737.459172: Request or response is too big for UDP; retrying
> with TCP

In krb5.conf, set:

    [libdefaults]
        udp_preference_limit = 0

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev