According to https://lists.samba.org/archive/samba-technical/2013-January/090092.html, using smart-card authentication requires that the DC send out the password hash to the client in response to the Kerberos login to allow successful use of the DPAPI extensions and SSO-functionality (i.e., the ability to create a correct NTLMSSP packet). Having set up smart card authentication in a testbed, I can still see the corresponding behaviour in a current Samba. I have added "kdc:require spn for service = no" for the configuration which at least according to my Samba logs solves at least part of the original problem, but DPAPI still fails to function on clients. I should be able to debug and/or implement the corresponding changes required to the Kerberos authentication as a patch (from what I gather, it should be in source4/auth/kerberos/kerberos_pac.c), but currently need a hint at where to start looking for the corresponding info on the actual format of the specific buffer: krb5pac.idl doesn't seem to contain the necessary data structure to implement this, and I haven't found specific information on the packet and it's use in the microsoft documentation yet. Thanks for any hints!
G'Day, My first feeling about this is 'drat'. We had hoped to avoid having to implement this horrible hack. It is entirely practical, just totally horrid in terms of security. MS-PAC and MS-KILE should have the details you need for the PAC. In particular, see MS-PAC 2.6.4 NTLM_SUPPLEMENTAL_CREDENTIAL The key thing we need here is tests, because most users do not use smart cards, we need strong tests to ensure we don't break this.
Created attachment 11337 [details] Implement PAC_CREDENTIAL_* structures.
Created attachment 11338 [details] Store and pass NT/LM-password through auth_user_info_dc structure for PAC_CREDENTIAL_SECPKG.
Created attachment 11339 [details] Pass through PKP reply from Heimdal to allow PAC_CREDENTIAL_DATA encryption. This only works with the embedded Heimdal implementation at the moment, as it changes calling conventions for kerberos5 and windc modules.
Created attachment 11340 [details] Implement the actual PAC_CREDENTIAL_* formatting/serialization in pac-glue and use it.
The four attached patches - applied in the order that they were posted - is a more or less verbatim implementation of the PAC_CREDENTIAL_INFO specification from MS-PAC. Currently, it does not seem to work according to Microsofts wishes (at least, I can't use Smartcard authentication successfully to authenticate against a TS session from my local system), but I will try to gather more data on this through local debugging on a domain-joined system (and which has the SmartCard reader directly connected to it) tomorrow, hopefully with a functioning implementation coming soon.
Oh, just as a side-note: the patch is against 4.1.19 which is the primary version currently in use at this specific site, but the patches apply more or less cleanly against the 4.2-branch too.
Thanks for all your efforts here. If you could please do your work on git master, that will help a lot. We are also trying to update to current Heimdal, so patches to Heimdal need to be upstreamed there as well. I realise this is a pile of extra work, but otherwise this will remain a site-specific patch, and that would be unfortunate.
(In reply to Andrew Bartlett from comment #8) I'm wondering if we better change the interface that provides the pac, so that we can provide all kinds of AuthorizationData, as Windows KDC add supported enctypes and other stuff to a ticket.
(In reply to Stefan Metzmacher from comment #9) https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-smart has a working implementation, see https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=970aa90e5d454161977a03 and https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=51ae26b470612fefa60592 I need to clean this up a lot, but at least we know where to go.
Greetings, I've been working to resolve an issue I'd seen with smartcard authentication for a couple of weeks now, something in this thread seems to resolve the issue, and I'm here to add my experiences to the record as well as promote the patch (and thank you for the work on this). The problem is manifest when logging into a domain using a smart card from windows 10 where the authenticating user is a member of the builtin\administrators group. I had originally thought the problem was the domain admins group but when I tried to fall back to only the local (specific) machines admin group the problem persisted (domain admins being a member of the builtin administrators group). So specifically an admin account that authenticates with smartcards exhibits this issue. Non admin accounts work fine for some reason, and password authentication as an admin works fine. The issue can be seen by setting chrome to "re-open last tab", and also by logging in to one drive. After a clean restart of the machine followed promptly (once the network is up for the auth) by smartcard admin login, opening chrome results in non-loading tabs with a "counter clockwise spinner", which indicates it is still attempting to establish the network connection (clockwise spinner would indicate loading/waiting for data). This can be reproduced on all sites. Simultaneously OneDrive will lose the authentication credentials to the cloud account and request re-authentication. Chrome will eventually time out things and say it couldn't contact your sync server if configured. Interestingly even while the main chrome window is locked in this state, an incognito window will just work immediately. I suspect this is all due to local credential encryption, and understandably the need for an interchangable (between authentication methods) wrapping secret, which lead me to find other threads talking about the deviation in the NThash response and speculating from there. Presumably incognito mode doesn't attempt credential store access and thus circumvents the issue. It all kind of adds up at that point, when i log in with the password it doesn't need the hash and can unwrap credentials, otherwise its dependant on the DC. Something about administrative priviledges is important but I don't understand this part (i've seen a LOT of errors debugging this, and little idea which of them are standard noise and which are truely problematic) I've attempted the following configurations which reproduce the problem, all with a windows 10 work station which I have frequently "reset" to a fresh install (over a dozen times by now). Samba on gentoo's main repository (4.2.4 or something?) exhibits this issue Samba-4.4.4 (latest) on gentoo exhibits the same Samba distro packages (?) from ubuntu on 16.04 exhibit this Samba 4.4.4 compiled on ubuntu 16.04 exhibits this Samba git tree with "git checkout master" compiled on gentoo exhibits this problem What worked in the end for me was git cloning the main samba tree and (excuse my abuse of git because I've not used it in a truely multiuser environment) (hopefully) pulling in your changed with the following commands git clone git://git.samba.org/samba.git git remote add wip git://git.samba.org/metze/samba/wip.git git checkout wip/v4-4-smart-2 distclean/configure/make/install (if i should have done otherwise, like merge or something, please let me know, happy to do more testing, using this in a 'pre-deployment-testing kinda way' mostly) I compiled and deployed, and this now lets me log in my test domain admin account via smart card and doesn't exhibit this issue. I've also since re-added domain admin to my standard user account and verified it continues to function fully. It was hard discovering this fix and since I suspect its new to Windows 10 (i'm sure this worked with win 7 when i did it before) it might become more important sooner or later. I also created a script which downloads and compiles samba from scratch on a fresh installed Ubuntu 16.04 server, creates a CA, does the DC certs+config and makes a smartcard P12, because I ended up reinstalling everything so much over the last 2 weeks having a completely reproducable environment seemed useful (and time saving). If this is useful in some way, let me know what I can do with it. Many thanks to all involved in the samba project. Iain
(In reply to Iain Price from comment #11) Thanks for the feedback and testing. The patches should hopefully part of one of the next releases.
Fixed in Samba 4.5.0rc1 with commits up to and including 1854252816bf19b9afd104098e750d8495ad85b6