#2 Implement support for importing enterprise names
Closed: Fixed Opened by simo.

Enterprise names are generally email addresses and they should not split into username and domain fields on the '@' character as the whole username is the email address.

However GSSAPI does not have an enterprise type for names.

Needs more research as the same problem affects the krb5 mechanism.


FWIW when I use 'curl --ntlm -u david.woodhouse@intel.com:foo' it looks like this:

> Authorization: NTLM TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA=
< WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAwADADgAAAAGgokCyVwOUNCNNJwAAAAAAAAAALQAtAA7AAAABQLODgAAAA9BTVICAAYAQQBNAFIAAQAYAEYATQBTAEUAUwBQAFIAQQBVAFAAMAAyAAQAJABhAG0AcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQADAD4AZgBtAHMAZQBzAHAAcgBhAHUAcAAwADIALgBhAG0AcgAuAGMAbwByAHAALgBpAG4AdABlAGwALgBjAG8AbQAFABwAYwBvAHIAcAAuAGkAbgB0AGUAbAAuAGMAbwBtAAAAAAA=
> Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAAAAABwAAAAGQAZAHAAAAAJAAkAiQAAAAAAAAAAAAAABoKJAnRrxKDUGdLvAAAAAAAAAAAAAAAAAAAAADeH4Txqugq90DFBmAJma/GsIogp9DISgGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb21zaGlueWJvb2s=

That final Authenticate packet is:

00000000  4e 54 4c 4d 53 53 50 00  03 00 00 00 18 00 18 00  |NTLMSSP.........|
00000010  40 00 00 00 18 00 18 00  58 00 00 00 00 00 00 00  |@.......X.......|
00000020  70 00 00 00 19 00 19 00  70 00 00 00 09 00 09 00  |p.......p.......|
00000030  89 00 00 00 00 00 00 00  00 00 00 00 06 82 89 02  |................|
00000040  74 6b c4 a0 d4 19 d2 ef  00 00 00 00 00 00 00 00  |tk..............|
00000050  00 00 00 00 00 00 00 00  37 87 e1 3c 6a ba 0a bd  |........7..<j...|
00000060  d0 31 41 98 02 66 6b f1  ac 22 88 29 f4 32 12 80  |.1A..fk..".).2..|
00000070  64 61 76 69 64 2e 77 6f  6f 64 68 6f 75 73 65 40  |david.woodhouse@|
00000080  69 6e 74 65 6c 2e 63 6f  6d 73 68 69 6e 79 62 6f  |intel.comshinybo|
00000090  6f 6b                                             |ok|

I also filed this Fedora bug for the fact that I can't get it to work with KRB5 via GSSAPI:
https://bugzilla.redhat.com/show_bug.cgi?id=1020913

Fixed using special casing for now:
e6370d26843206bcf7e418d3c3014611fdecc489

Metadata Update from @simo:
- Issue assigned to simo

Metadata