SAMBA-AD

(Peter Gietz)

History Samba 3 was a good and stable product that could replace windows NT4 file and print services. Then MS created Active Directory, for which of course the SAMBA project wanted to also create an alternative. After some unhappy communications with OpenLDAP team they decided to implement an own LDAP server but underestimated the effort. Thus only after many years they were able to produce a production ready solution. Now it is ready to use and the question is who is already doing respective migration projects.

Why migrate from MS AD to Samba?

• Client Access Licenses (CAL) needed on every desktop computer that authenticates with AD
• Possible Performance Advantages
• More Management Tools, MSA can also be used
• Stability has reached production state
• Avoid AD Data being pushed to Azure in the future since AD may not be available on premise in the future

Some user think that the interfaces provided by MS are good and easy to use and are happy with CALs

What happens with ADFS

• if you want a SAML compliant
• Also using WS-Fed

OpenLDAP —+—-IdP—–[SAML]——ADFS(SP)–[WS-Fed]—SharePoint | | + [sambaLDAP]-Smaba-SMB

                   What would be needed is not only an alternative to AD but also to ADFS including WS-Fed.
                   Client library for ADFS still uses WS-Fed

Shibboleth SP supports WS-FED: “The SP can act as a WS-Federation Passive Profile relying party in the same fashion that it supports SAML” https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPADFS

Other government wanted to analyse open source alternatives, but without replacing MS AD, you still needed CALs for every desktop

In general it is hard to replace MS infrastructures, since user expectation is that nothing should change user interface wise, e.g. migrate away from Exchange without outlook users