Re: Enterprise Active Directory support question

[Stef Walter <stefw gnome org>]

On 22.02.2013 13:13, stefan skoglund(agj) wrote:
> mån 2013-02-11 klockan 09:52 +0000 skrev David Woodhouse: 
> > On Mon, 2013-02-11 at 08:29 +0100, Stef Walter wrote:
> > > > In GNOME 3.6 Enterprise logins was introduced. This feature is very
> > > > attractive for enterprise deployments because it makes possible to
> > > > add GNOME workstations into Windows networks with Active Directory.
> > > > My understanding of this feature is that it only enables users to
> > > log
> > > > on their GNOME workstations, so it doesn't enable them to use the
> > > > shared folders or network printers of their domains without login
> > > > again for every shared resource.
> > >
> > > Well it should do those things. I know that the shared folders does
> > > work. For example, we tested it in Fedora:
> >
> > And automatic login with NTLM, and keeping a Kerberos TGT valid, are
> > both mostly solved problems too. Although we do need to dust that work
> > off and merge it.
>
> With MIT Kerberos it is possible in /etc/krb5.conf to force checking of
> the KDC but normally it means that the client process needs read access
> to /etc/krb5.keytab which is only readable by root.

When you say 'MIT Kerberos' do you mean when using pam_krb5?

> Which means that gnome-shell/gnome-screensaver can't check the
> responding KDC when unlocking the session = a possibility of
> KDC-spoofing.

Yes, that's why we use sssd to perform the authentication.

> Any designs for this problem which doesn't requires 'sssd' ?

Sure. You can choose to use winbind to do authentication, even with the
GNOME Control Center integration. Configure it in /etc/realmd.conf

See: http://www.freedesktop.org/software/realmd/docs/guide-configuring.html

> One possibility is to install in a world-readable some other ticket with
> only usage to permit screensaver to check KDC validity.
>
> pam_krb5 at login time uses (i think) the host/'fqdn of client` ticket
> to check KDC identify.

It's certainly possible to come up with ways to work around this for a
particular deployment.

But the real solution we're integrating and going after here is to use
sssd to do the authentication the "right way" in a centralized process
along with all the other capabilities that it provides.

Cheers,

Stef