Bug 13764 - Hyper-V AD member in samba 4 AD create issues when using kerberos for hyper-v-specific functions, because of SPN with space character.
Summary: Hyper-V AD member in samba 4 AD create issues when using kerberos for hyper-v...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: All Windows 10
: P5 normal (vote)
Target Milestone: ---
Assignee: Jennifer Sutton
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-28 13:36 UTC by Kacper
Modified: 2024-06-14 07:54 UTC (History)
4 users (show)

See Also:


Attachments
attempt to fix (1.92 KB, patch)
2020-10-13 13:02 UTC, Mantas Mikulėnas (grawity)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper 2019-01-28 13:36:02 UTC
Hello,
samba version: I tested since 4.5.x (4.6.x, 4.7.x and 4.8.4 as latest)
Windows Hyper-V: tested on Server 2012, 2012R2 and 2016.

Microsoft uses 3 distinct service principal names for servers with hyper-v function:
Hyper-V Replica Service/HOSTNAME.fqdn

Microsoft Virtual System Migration Service/HOSTNAME.fqdn

Microsoft Virtual Console Service/HOSTNAME.fqdn 

They are required for: virtual machine live migration, virtual machine reqplication and management.

The issue at hand are the "space" characters in SPN. Unfortunately they are specific for microsoft, and they're hard coded, microsoft will specifally look for these SPN's when using hyper-v features.

SPN request reaches DC fine, but when doing LDB search for this SPN it adds escape character because of the spaces and therefore fails to find it. Right now my workaround is to add all 3 SPN with an escape character that is:
Hyper-V\ Replica\ Service/HOSTNAME.fqdn etc.

I'm aware of this issue since at least samba 4.5 and windows server 2012. Right now I tested it with samba 4.8.4 and windows server 2016 with hyper-v role.

Here are log snippets I posted on samba mailing list in 2017:
 Kerberos: TGS-REQ BM-SRV-5$@MYDOMAIN.COM.XYZ from
    ipv4:192.168.1.10:56993 for Hyper-V\ Replica\
    Service/BMSRV-WIN10.mydomain.com.xyz at MYDOMAIN.COM.XYZ [canonicalize,
    renewable, forwardable]
    [2017/03/16 10:55:07.246904, 4]
    ../source4/dsdb/samdb/cracknames.c:169(LDB_lookup_spn_alias)
    LDB_lookup_spn_alias: no alias for service Hyper-V Replica Service
    applicable
    [2017/03/16 10:55:07.246971, 3]
    ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
    Kerberos: Searching referral for BMSRV-WIN10.mydomain.com.xyz
    [2017/03/16 10:55:07.247028, 3]
    ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
    Kerberos: Server not found in database: Hyper-V\ Replica\
    Service/BMSRV-WIN10.mydomain.com.xyz at MYDOMAIN.COM.XYZ: no such entry
    found in hdb
    [2017/03/16 10:55:07.247053, 3]
    ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
    Kerberos: Failed building TGS-REP to ipv4:192.168.1.10:56993

    log from wireshark (earlier attempt but same issue, this time when
    trying to start live migration from BM-SRV-5 to BMSRV-WIN10):

    req-body
    Padding: 0
    kdc-options: 40810000 (forwardable, renewable, canonicalize)
    realm: MYDOMAIN.COM.XYZ
    sname
    name-type: kRB5-NT-SRV-INST (2)
    sname-string: 2 items
    SNameString: Microsoft Virtual System Migration Service
    SNameString: BMSRV-WIN10
    till: 2037-09-13 02:48:05 (UTC)
    nonce: 17847174
    etype: 5 items
    enc-authorization-data


    error:
    krb-error
    pvno: 5
    msg-type: krb-error (30)
    ctime: 2017-03-16 08:01:23 (UTC)
    cusec: 128
    stime: 2017-03-16 08:01:23 (UTC)
    susec: 66964
    error-code: eRR-S-PRINCIPAL-UNKNOWN (7)
    realm: <unspecified realm>
    sname
    name-type: kRB5-NT-UNKNOWN (0)
    sname-string: 0 items

Right now i tried to get some new log from more recent samba (4.8.4), but even with samba log level 10 I couldn't get similar info in log (did audit logging with JSON change this?), but tcpdump output is the same, so I suppose supplied log from 2017 is still valid.

If any additional info is required I do my best to supply it (if I manage to get samba 4.8 logging properly...)

Regards,
Kacper
Comment 1 Mantas Mikulėnas (grawity) 2020-10-13 13:02:59 UTC
Created attachment 16281 [details]
attempt to fix

Having the same issue with 4.13 as well, but instead of putting the mangled principals in LDAP, I attempted to fix it in source.
Comment 2 Douglas Bagnall 2020-10-20 21:13:48 UTC
(In reply to Mantas Mikulėnas (grawity) from comment #1)

grawity: are you able to trigger a CI run on gitlab?

https://wiki.samba.org/index.php/Samba_on_GitLab
Comment 3 Mantas Mikulėnas (grawity) 2020-10-21 09:26:03 UTC
(In reply to Douglas Bagnall from comment #2)

No, I don't have access to the CI repository. (I don't usually participate in Samba devel -- this patch is just what I wrote for the small domain at work. Also no idea about writing tests, though test_kinit_mit.sh looked like it could fit a call to `kvno`.)