mail archive ubuntu-directory.lists.ubuntu.com
(List home) (Recent threads) (280 other Ubuntu lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- This list contains about 45 messages, beginning Oct 2006
- This list doesn't seem to be active
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
NetworkAuthentication/Client
Ad
https://wiki.ubuntu.com/NetworkAuthentication... I have been working on this ... rather large document? It outlines my current plans with regards to implementing the first step of client support for Ubuntu. I would appreciate a read over by any interested parties. Please leave comments at the bottom. Sorry for the prose form. Writing helps me get the ideas in my own head. Also, please join us on the ubuntu-directory mailing list. I would appreciate any long threads about this being sent to the copy of the mail I sent there. Don't clutter ubuntu-devel.
I have read this paper and think it makes sense. Just a few comments from my side. If you want to integrate workstations into Active Directory KDC's please read http://www.microsoft.com/technet/prodtechnol/... For any network based services like smtp, imap, ldap etc. I would implement SASL GSSAPI authentication, thus libsasl and libgssapi are involved as well. With regard to PAM, consider the use of pam_unix2 instead of pam_krb5. -DieterJerry Haltom writes: > https://wiki.ubuntu.com/NetworkAuthentication... > > I have been working on this ... rather large document? It outlines my > current plans with regards to implementing the first step of client > support for Ubuntu. > > I would appreciate a read over by any interested parties. Please leave > comments at the bottom. > > Sorry for the prose form. Writing helps me get the ideas in my own head. > > Also, please join us on the ubuntu-directory mailing list. I would > appreciate any long threads about this being sent to the copy of the > mail I sent there. Don't clutter ubuntu-devel.
Actually, you want to use pam_winbindd, and have winbindd handle the ticket management. You also want to stay away from ktpass, and use Samba's net join instead. Andrew BartlettOn Tue, 2006-10-31 at 10:14 +0100, Dieter Kluenter wrote: > Jerry Haltom writes: > > > https://wiki.ubuntu.com/NetworkAuthentication... > > > > I have been working on this ... rather large document? It outlines my > > current plans with regards to implementing the first step of client > > support for Ubuntu. > > > > I would appreciate a read over by any interested parties. Please leave > > comments at the bottom. > > > > Sorry for the prose form. Writing helps me get the ideas in my own head. > > > > Also, please join us on the ubuntu-directory mailing list. I would > > appreciate any long threads about this being sent to the copy of the > > mail I sent there. Don't clutter ubuntu-devel. > > I have read this paper and think it makes sense. Just a few comments > from my side. > If you want to integrate workstations into Active Directory KDC's > please read > http://www.microsoft.com/technet/prodtechnol/... > For any network based services like smtp, imap, ldap etc. I would implement > SASL GSSAPI authentication, thus libsasl and libgssapi are involved as > well. > With regard to PAM, consider the use of pam_unix2 instead of pam_krb5.
I'm all for using Winbind, but I have to question the long term feasibility of doing so. Yes, our first goal is AD... because that can get us market share. But it's not our last goal. Along with joining AD, I would like it to be a very small step to join other LDAP/Kerberos directories. For these, winbind isn't going to work... and so it's going to have to do it another way. A dedicated ticket daemon... plain pam_krb5. There's no replacement for winbind for 'net ads join' on AD... but the other stuff... So, winbind will certainly be used, but it doesn't make the other stuff go away.
Good ideas all and all, but why are we keen on building a Kerberos/LDAP -solution that wouldn't be compatible with winbind on the client side, as well as Windows workstations? And on the NSS side, Winbind's solution is ready, mature and quite featureful, whereas getting an LDAP NSS module to do the work would require way too much to get it to even edgy+2, if this project doesn't get big boost from Canonical. And on the PAM side, the new winbind PAM module knows how to do credential caching, so that again would simplify the implementation somewhat. Because of some of these reasons, SuSE, which I believe is the distro furthest on this road, chose winbind. Naturally they didn't want to lock in, but that's why they have an easy and simple configuration tool to set the authentication up to your environment. (We need this anyway, so why shouldn't winbind be one of the options it provides? Why do we have to use "clean LDAP/Krb"?) And finally, if you're fixated on getting a simple and static PAM/NSS-solution, you'll probably have to start creating proxy PAM/NSS-modules, which doesn't quite make sense considering you're solving the problem that PAM/NSS was supposed to solve. That's why PAM and NSS are modular: so you can have multiple modules that implement authentication. Best regards,On 10/31/06, Jerry Haltom wrote: > > Actually, you want to use pam_winbindd, and have winbindd handle the > > ticket management. > > I'm all for using Winbind, but I have to question the long term > feasibility of doing so. Yes, our first goal is AD... because that can > get us market share. But it's not our last goal.
Yes. Winbind can solve the problem. And yes, it might be the solution for pure AD authentication on Fiesty. We might be able to do it in that time frame. Beyond that though, Winbind is not a solution. Any work put into making Winbind work perfectly in the NSS and PAM (!password) cases would be discarded as soon as we target other directory services. Winbind is still a great stop gap. Thing is, we know it exists, and we understand how it operates. I would like to spend some time upfront investigating what it would take to make a long term solution.> Good ideas all and all, but why are we keen on building a > Kerberos/LDAP -solution that wouldn't be compatible with winbind on > the client side, as well as Windows workstations?I completely agree. I doubt much of this is going to happen unless Canonical is willing to step in. We have no developers who have the time to work on it. My regular job takes most of my time. I want to put together a cohesive plan, and then bring it in front of the powers that be.> And on the NSS side, Winbind's solution is ready, mature and quite > featureful, whereas getting an LDAP NSS module to do the work would > require way too much to get it to even edgy+2, if this project doesn't > get big boost from Canonical.Same as above.> And on the PAM side, the new winbind PAM module knows how to do > credential caching, so that again would simplify the implementation > somewhat.We don't HAVE to, but it will get us further. Winbind only works against AD. I personally don't even use AD, I run a Heimdal/OpenLDAP setup. So this solution is useless for me. Some of my clients do use AD. So, after all that, if I was investing *MY* time, I would work towards not using Winbind.> Because of some of these reasons, SuSE, which I believe is the distro > furthest on this road, chose winbind. Naturally they didn't want to > lock in, but that's why they have an easy and simple configuration > tool to set the authentication up to your environment. (We need this > anyway, so why shouldn't winbind be one of the options it provides? > Why do we have to use "clean LDAP/Krb"?)Yes. NSS and PAM LDAP/Kerberos support are in a terrible shape. To be honest, I sort of wish the Samba guys had taken the work they'd put into Winbind and separated the generic Kerberos/LDAP parts of it out into components that could be usable separately without the Windows components. Actually, that might be a good path to investigate. Winbind has a lot of great logic in it. Can we split that into Windows and non-Windows pieces? Andrew?> And finally, if you're fixated on getting a simple and static > PAM/NSS-solution, you'll probably have to start creating proxy > PAM/NSS-modules, which doesn't quite make sense considering you're > solving the problem that PAM/NSS was supposed to solve. That's why PAM > and NSS are modular: so you can have multiple modules that implement > authentication.