Winbind - functionality extension needed

[Ondrej Valousek]

Hi all,

I would like to ask if it would be possible to extend the functionality
of the winbind and nss_winbind.so to cover other system databases (not
only passwd and group).
The trick is, that as of Windows server 2003 R2 or 2008, AD schema
already contains all necessary rfc2307 attributes needed to store unix
system databases in AD - so the obvious question would be, if we can use
winbind & nsswitch.conf and store all databases in Active Directory.

The immediate answer is, that nss_ldap (from PADL software) does this -
but unfortunately not effectively. Why?
1. nss_ldap does no caching (no daemon running)
2. By default, you need to authenticate to AD in order to access it via
LDAP. That leaves us 2 options:
a) Allows anonymous access to AD
b) configure something like "proxy" user to access AD

I do not like neither of those options - the most elegant solution would
be to use machine Kerberos credentials to access AD - the same way
winbind does.

So hence my question - would it be possible to extend the functionality
of winbind or am I completely wrong /bad idea here?
Many thanks for any feedback.

Ondrej

[Volker Lendecke]

On Wed, Jul 08, 2009 at 04:38:52PM +0200, Ondrej Valousek wrote:
> I would like to ask if it would be possible to extend the functionality
> of the winbind and nss_winbind.so to cover other system databases (not
> only passwd and group).
> The trick is, that as of Windows server 2003 R2 or 2008, AD schema
> already contains all necessary rfc2307 attributes needed to store unix
> system databases in AD - so the obvious question would be, if we can use
> winbind & nsswitch.conf and store all databases in Active Directory.

If I'm not completely wrong, winbind does all this. See
"idmap backend = ad" and "winbind nss info = rfc2307".

Volker

[Gerald Carter-3]

Ondrej Valousek wrote:
> Hi all,
>
> I would like to ask if it would be possible to extend the functionality
> of the winbind and nss_winbind.so to cover other system databases (not
> only passwd and group).
...
> The immediate answer is, that nss_ldap (from PADL software) does
> this - but unfortunately not effectively. Why?
> 1. nss_ldap does no caching (no daemon running)

Not entirely true.  There several options like nss-ldapd, the similar
overlay in slapd, nscd, etc....

> 2. By default, you need to authenticate to AD in order to access it via
> LDAP. That leaves us 2 options:
> a) Allows anonymous access to AD
> b) configure something like "proxy" user to access AD

Or use nscd with the system keytab and GSSAPI.  You could use
Samba to manage the system keytab file.





cheers, jerry

[Ondrej Valousek]

> If I'm not completely wrong, winbind does all this. See
> "idmap backend = ad" and "winbind nss info = rfc2307".
>
>  
Well it does - but only for "passwd" and "group" NSS databases. It can
not handle other databases like services, protocols, networks..... :-(
Ondrej

[Gerald Carter-3]

Volker Lendecke wrote:

> On Wed, Jul 08, 2009 at 04:38:52PM +0200, Ondrej Valousek wrote:
>> I would like to ask if it would be possible to extend the functionality
>> of the winbind and nss_winbind.so to cover other system databases (not
>> only passwd and group).
>> The trick is, that as of Windows server 2003 R2 or 2008, AD schema
>> already contains all necessary rfc2307 attributes needed to store unix
>> system databases in AD - so the obvious question would be, if we can use
>> winbind & nsswitch.conf and store all databases in Active Directory.
>
> If I'm not completely wrong, winbind does all this. See
> "idmap backend = ad" and "winbind nss info = rfc2307".

Hey Volker,

These are still just for user/group information.  The original
request was for things like "networks", "protocols", etc....
if I understood correctly.





cheers, jerry
--
=====================================================================
http://www.plainjoe.org/
"What man is a man who does not make the world better?"      --Balian

[Volker Lendecke]

On Wed, Jul 08, 2009 at 10:02:50AM -0500, Gerald Carter wrote:
> These are still just for user/group information.  The original
> request was for things like "networks", "protocols", etc....
> if I understood correctly.

Ignore me then, sorry for the noise.

Volker

[Ondrej Valousek]

> Not entirely true.  There several options like nss-ldapd, the similar
> overlay in slapd, nscd, etc....
>  

Maybe nss_ldapd would do the job - but definitely a daemon reading
keytab file (managed by samba) would be necessary.
But from what I see nss_ldapd can not read Kerberos keytab (and besides,
will it go in RHEL?) and nscd only solves caching.....

[Gerald Carter-3]

Ondrej,

>> Not entirely true.  There several options like nss-ldapd, the similar
>> overlay in slapd, nscd, etc....
>>  
>
> Maybe nss_ldapd would do the job - but definitely a daemon reading
> keytab file (managed by samba) would be necessary.
> But from what I see nss_ldapd can not read Kerberos keytab (and besides,
> will it go in RHEL?)

The nssldapd overlay is part of upstream OpenLDAP.  If you
are bound by what's in RHELs then really extending Winbind doesn't
help you much either.

> and nscd only solves caching.....

No.   nscd also solves the problem of calling into nss_ldap
in the user context (i.e. permissions on the system keytab).

I'm just offering suggestions.  Having winbindd deal with
other NIS maps seems a bit out of mainstream IMO.  But it's not
really my call.





cheers, jerry
--
=====================================================================
http://www.plainjoe.org/
"What man is a man who does not make the world better?"      --Balian

[Andrew Bartlett]

On Wed, 2009-07-08 at 17:02 +0200, Ondrej Valousek wrote:
> > If I'm not completely wrong, winbind does all this. See
> > "idmap backend = ad" and "winbind nss info = rfc2307".
> >
> >  
> Well it does - but only for "passwd" and "group" NSS databases. It can
> not handle other databases like services, protocols, networks..... :-(

Why would services or protocols change often enough to maintain with
anything other than a package manager?

Perhaps you can shed some light on your proposed use case?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Ondrej Valousek]

> No.   nscd also solves the problem of calling into nss_ldap
> in the user context (i.e. permissions on the system keytab).
>
>  
Wow! You are right. BUT: nscd runs under "nscd" user account (not
speaking about the SELinux policy) so even nss_ldap would be called in
"nscd" user context. And besides, nss_ldap can not directly use the
system Kerberos keytab file. So nscd does not help me either.
> I'm just offering suggestions.  Having winbindd deal with
> other NIS maps seems a bit out of mainstream IMO.  But it's not
> really my call.
>  
I agree, having nss_ldapd would be the best solution, indeed.
Ondrej

[Ondrej Valousek]

> Why would services or protocols change often enough to maintain with
> anything other than a package manager?
>
> Perhaps you can shed some light on your proposed use case?
>  
Ok you are right, I do not change services that often, but sometimes I
do - and given the fact that all the necessary framework in winbindd is
already there, it seems to me obvious and simple to extend functionality
(but I might be wrong). Maintaining this via package manager or flat
files is far from being elegant.

And to be absolutely honest, my dream is to have this integrated with
automounter, too. Automounter can store maps in ldap repository and in
Win2008 AD, too. Support for finding DC's via DNS SRV records has been
added to autofs recently and guess how was it done?
By "stealing" a significant part of Samba code. I can not help myself,
but this seems to me like an unnecessary duplication of effort.

It would be just *perfect* if winbind could provide some kind of
universal interface to whatever Unix service (like automounter). This
way autofs developers could concentrate themselves on autofs operation,
leaving all the server discovery/negotiation/authentication/caching on
winbind.

Ok I understand that automounter is bit too special here so we could
start by services/protocols/whatever else database.

Or perhaps my dreams are too wild :-) ?
Ondrej