Re:XPS9350-macOS – macOS patches for Dell XPS 13 9350
by snuxoll on Tuesday January 31, 2017 @06:45PM
(#13536591)
Are you looking at a BYOD setup of some fashion? I hate AD as much as any good Linux admin, but I'm curious what the use-case for non-domain joined machines accessing kerberized services is.
Re:XPS9350-macOS – macOS patches for Dell XPS 13 9350
by vetinari on Wednesday February 01, 2017 @03:19AM
(#13539234)
Exactly, BYOD setup. As I hinted, single organization and several independent people working together with their private laptops, using several on-premises services and right now, way too many passwords.
Towards AD, I'm kind of ambivalent. However, it's all or nothing approach is not suitable right now. What I need now is just the Kerberos, and the willingness of the apps to use it.
Background: think of a group of freelancers, working together with one organization. The freelancers have each their own BYOD laptop and there are few servers, that provide services. Until now, each of these services had their own unique user database, so every user had to remember several passwords.
We want to change that and are currently experimenting with FreeIPA. In the lab, everything works as it should - with macOS and Linux. Even Windows machines, that are joined to a domain with the trust set up with FreeIPA domain work (that would be some of the servers). However, the standalone Windows machines are the problem. So far, only Firefox and Putty can use GSSAPI. Chrome uses SSPI, even PostgreSQL windows client supports only SSPI, and now I’m playing with the svn klient to figure out, whether it can use GSSAPI. For smb shares, Windows insist on NTLM (and on the Linux side, sssd doesn’t support NTLMSSP), so there I’m looking into plain LDAP backend for Samba. At least they could enter the password into the Explorer dialog and get to the files.
For webapps, it is actually quite simple - just use some IDP. Those who cannot obtain a tgt, will log-in using forms. It doesn’t really matter whether they put their password into web form or into kinit or ticket viewer. It’s the non-web services, that are the problem.
The other solution would be to let them RDP into terminal server and let them do everything there. This solution slightly complicates the work for the users, because they will have to use some locally installed apps anyway.