Hi all, I would like to set up windows Hello (in the sense user and management are pressuring me) but for both option the schema would need to be at least 87 (windows 2016). I looked on the roadmap, bugzilla but couldn't find anything regarding this topic. Would you know when this version would be available and what is needed in order to achieve so? As a separate question, do you know good alternative to windows hello for business (pin/fingerprint login)? Best regards and thanks @samba_team for their hard work -------------- 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/20200905/7827c6b1/signature.sig>
On Sat, 2020-09-05 at 12:31 +0200, mailist via samba wrote:> Hi all, > > I would like to set up windows Hello (in the sense user and > management > are pressuring me) but for both option the schema would need to be at > least 87 (windows 2016). I looked on the roadmap, bugzilla but > couldn't > find anything regarding this topic. Would you know when this version > would be available and what is needed in order to achieve so? > > As a separate question, do you know good alternative to windows hello > for business (pin/fingerprint login)?G'Day, I'm sorry for taking to so long to reply. 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. 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. 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. Depending on the size of your organisation you might want to help us make progress on some of this, but in the meantime I suggest using a traditional smart card or a software based system that integrates with whatever is on your devices (turning them into a bulky smart card) without going via the actual Hello protocols. If you did really want to proceed, I would look at funding another schema upgrade, testing real ADFS against Samba and seeing what APIs it hits and then implementing those. At least the Windows server would only be needed at enrolment, I think. I would love for Samba to do more here, but it need engineering resources and a motivated backer. Sorry I can't give you better news right now! Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
Hi, thank you for your answer :) ohhh that is new I thought that samba 4 was to this day incompatible with a schema update >= v67 (it is I think somewhere it is written in the documentation that the reason why windows > 2016 can't be used as domain controller is partly due to the schema that is what bothered me)) I already have set up an ADFS (win 2016) (works with heimdal krb without problems, MIT seems to also work). The problem is with the enterprise Device Registration Service that requires a schema of windows 2016 (which I thought was not yet supported by samba). For me making heimdal do this would be pointless. The idea that I had was to have a windows 2012 R2 ADDC with whom the ADFS would be only talking (great no krb problems) so the key trust model would technically work :) the only point missing was the schema. Thank you so much for your answers you actually helped me a lot :) Yes the smart card login was the alternative thought (probably even better but users like fashion). (and yes it looks like ADFS is only needed for the enrollment but with windows better wireshark everything) I am just an Ops but I would love to help if there is smth I can do. Thx for the great work that you guys are doing Vincent On 9/11/20 6:07 AM, Andrew Bartlett via samba wrote:> On Sat, 2020-09-05 at 12:31 +0200, mailist via samba wrote: >> Hi all, >> >> I would like to set up windows Hello (in the sense user and >> management >> are pressuring me) but for both option the schema would need to be at >> least 87 (windows 2016). I looked on the roadmap, bugzilla but >> couldn't >> find anything regarding this topic. Would you know when this version >> would be available and what is needed in order to achieve so? >> >> As a separate question, do you know good alternative to windows hello >> for business (pin/fingerprint login)? > G'Day, > > I'm sorry for taking to so long to reply. > > 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. > > 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. > > 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. > > Depending on the size of your organisation you might want to help us > make progress on some of this, but in the meantime I suggest using a > traditional smart card or a software based system that integrates with > whatever is on your devices (turning them into a bulky smart card) > without going via the actual Hello protocols. > > If you did really want to proceed, I would look at funding another > schema upgrade, testing real ADFS against Samba and seeing what APIs it > hits and then implementing those. At least the Windows server would > only be needed at enrolment, I think. > > I would love for Samba to do more here, but it need engineering > resources and a motivated backer. > > Sorry I can't give you better news right now! > > Andrew Bartlett > >-------------- 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/20200911/52ed1a7c/signature.sig>
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