Hi Andrew, I'm very interested in using Windows Hello for Business in small business environments, with Samba as the AD DC. I'm sorry that I don't have great news. The schema upgrade is the easy> part - we could do that by obtaining new schema from Microsoft: > > https://www.microsoft.com/en-nz/download/confirmation.aspx?id=23782 > (and yes, the licence terms are something we can use!) > > Even upgrading the schema in-place isn't too hard, they even publish some > of the required parts here: > > https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/identity/ad-ds/deploy/Schema-Updates.md > Creative Commons Attribution 4.0 International Public License (w00t!) > > So, a new schema is 'just' a matter of importing those and using the great > tools that Garming Sam wrote a couple of years back to ingest it. >Is this all that would be required to enable a deployment based upon a traditional PKI?> And at the base, Windows Hello is just PKINIT under the hood, and our > Heimdal KDC knows about that. Teaching it about the self-signed > certificates used (rather than traditional CA enrolment) also wouldn't > be impossible. >If I'm understanding you correctly, it sounds like the only significant change (and perhaps not even that significant) would be some coding to support the self-signed cert scenario. This all sounds really promising! What would it take to sponsor the development of this? Unfortunately, I don't have any developer resources to offer.> But the big trouble is that the 'Hello for buisness' enrolment process > is all wrapped up in a flow via Active Directory Federation Services, > and we have *none* of that stack. >I took a look at the slide deck presented at SambaXP 2019 ( https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/farooqi_sambaxp2019_WindowsHelloForBusiness.pdf) and specifically the provisioning process. I see what you mean about the requirement for ADFS, to enable a user friendly self registration process. However, for smaller environments, with a very low volume of new users being introduced, would it not be possible to forego the self provisioning process and substitute either a manual admin process or some light automation to generate key pairs on the client and push the necessary changes directly to the DC? This would essentially be a Windows Hello for Business minimum viable product. -- Mason
Hi Mason, On 9/26/20 9:34 AM, Mason Schmitt via samba wrote:> Hi Andrew, > > I'm very interested in using Windows Hello for Business in small business > environments, with Samba as the AD DC. >good luck I got it kind of working with :1 samba DC, 1 windows 2012 DC, 1 windows 2016 ADFS> > I'm sorry that I don't have great news. The schema upgrade is the easy >> part - we could do that by obtaining new schema from Microsoft: >> >> https://www.microsoft.com/en-nz/download/confirmation.aspx?id=23782 >> (and yes, the licence terms are something we can use!) >> >> Even upgrading the schema in-place isn't too hard, they even publish some >> of the required parts here: >> >> https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/identity/ad-ds/deploy/Schema-Updates.md >> Creative Commons Attribution 4.0 International Public License (w00t!) >> >> So, a new schema is 'just' a matter of importing those and using the great >> tools that Garming Sam wrote a couple of years back to ingest it. >> > > Is this all that would be required to enable a deployment based upon a > traditional PKI? >If you are using windows yes, if not then you would need to find a way to replace the EDRS (there is a good doc about it here https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning)> > >> And at the base, Windows Hello is just PKINIT under the hood, and our >> Heimdal KDC knows about that. Teaching it about the self-signed >> certificates used (rather than traditional CA enrolment) also wouldn't >> be impossible. >> > > If I'm understanding you correctly, it sounds like the only significant > change (and perhaps not even that significant) would be some coding to > support the self-signed cert scenario. >sounds like you want to do a certificate trust deployment seems the hardest because you would need a certificate authority that can talk with ADFS.> This all sounds really promising! What would it take to sponsor the > development of this? Unfortunately, I don't have any developer resources > to offer. > > > >> But the big trouble is that the 'Hello for buisness' enrolment process >> is all wrapped up in a flow via Active Directory Federation Services, >> and we have *none* of that stack. >> > > I took a look at the slide deck presented at SambaXP 2019 ( > https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/farooqi_sambaxp2019_WindowsHelloForBusiness.pdf) > and specifically the provisioning process. I see what you mean about the > requirement for ADFS, to enable a user friendly self registration process. > > However, for smaller environments, with a very low volume of new users > being introduced, would it not be possible to forego the self provisioning > process and substitute either a manual admin process or some light > automation to generate key pairs on the client and push the necessary > changes directly to the DC? This would essentially be a Windows Hello for > Business minimum viable product. >well you would have to bypass the whole registration process it is possible in theory but seems rather complex. I mean how do you register the pin then? Vincent> > -- > Mason >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20200928/ff953408/signature.sig>
> > Is this all that would be required to enable a deployment based upon a > > traditional PKI? > > > If you are using windows yes, if not then you would need to find a way > to replace the EDRS (there is a good doc about it here > > https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning > ) > >> >> But the big trouble is that the 'Hello for buisness' enrolment process > >> is all wrapped up in a flow via Active Directory Federation Services, > >> and we have *none* of that stack. > >> > > > > I took a look at the slide deck presented at SambaXP 2019 ( > > > https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/farooqi_sambaxp2019_WindowsHelloForBusiness.pdf > ) > > and specifically the provisioning process. I see what you mean about the > > requirement for ADFS, to enable a user friendly self registration > process. > > > > However, for smaller environments, with a very low volume of new users > > being introduced, would it not be possible to forego the self > provisioning > > process and substitute either a manual admin process or some light > > automation to generate key pairs on the client and push the necessary > > changes directly to the DC? This would essentially be a Windows Hello > for > > Business minimum viable product. > > > well you would have to bypass the whole registration process it is > possible in theory but seems rather complex.Yes, that's exactly what I'm proposing - bypassing the self registration process and instead doing an administrator controlled registration process. I think that entirely removes the need for ADFS and an MFA server.> I mean how do you register > the pin then? >The PIN isn't actually registered with the server. The PIN is only used to unlock the TPM on the PC, so that the TPM can use it's knowledge of the private key/certificate to authenticate against the server that contains a copy of the public key. The following is what I think the authentication (not provisioning) process boils down to: - User attempts to login and provides their PIN to unlock their TPM - Kerberos PKINIT authentication is attempted using the private key/certificate stored in the TPM With the above authentication process in mind, I'm thinking that the provisioning process could be boiled down to: - Configure the TPM to store a private key and protect it with a PIN - Write the public key to the correct location in LDAP (AD DC) - Configure the Windows Hello client on the PC As Andrew said, under the covers this is really just PKINIT and an AD schema upgrade. I think that most of the complexity lies in the self registration process. Of course self registration would be super convenient, but if I want that now, then I need to be willing to pay for some Windows Server licensing and ongoing maintenance and support of that platform. Does this make sense? Or have I dramatically oversimplified this? -- Mason
Hi Mason, I am not that experiences about it^^ I think that one first step would be to strip the registration (key trust on my side), and once that would have been done submit the results to the samba team and see if it is worth funding/implementing. As I am not part of the samba team I cannot say more. Vincent On 9/29/20 6:59 PM, Mason Schmitt wrote:> Hi Vincent, > > it does make sense and I would be into helping implementing it. > I am just affraid that like always with microsoft when you wireshark it > you have some not so nice surprises. > +1 > > > Thanks for offering to help implement this!? It sounds like you have > some past experience with things like this.? Other than a bug report or > two regarding Samba's file server, I don't have much experience with > this.? How could I best help you? > > -- > Mason-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20200929/b417f90b/signature.sig>
> I am not that experiences about it^^ > I think that one first step would be to strip the registration (key > trust on my side), and once that would have been done submit the results > to the samba team and see if it is worth funding/implementing. > As I am not part of the samba team I cannot say more. >It sounds like you're suggesting that you're going to strictly focus on what the regular day to day authentication process looks like for WHFB. In other words, just the PC to AD authentication piece and not the initial self-registration with ADFS. My guess is that subsequent steps would be to: - confirm what needs to be stored in LDAP and what format it is stored in - determine what registry keys and/or other configurations are changed on the PC, that tell Windows Logon to request a PIN for unlocking the TPM and then initiate the PKINIT authentication process I don't have access to a functioning WHFB environment, so I'm not sure how to help right now - other than offer encouragement and ideas. -- Mason