Bernardo Innocenti wrote:
Charles Lopes wrote:
So Heimdal can use an LDAP data store? Sweet. Thanks so much for your
post. I've wanted MIT krb5 to do this (in a non hacky way) for ages.
A data abstraction layer (DAL) patch that does just that has been just
been committed to the cvs of MIT KDC.
I just did a "cvs update" from MIT's repository and... yes!
Now it's there.
But where is the LDAP backend? Does one exist yet? Does it work
already? Is it compatible is it with Heimdal's hdb.schema?
(ok, too many questions :-)
I checked the cvs and the code imported after the tag
trunk-before-novell-dal-merge seems to be about thread support. I guess
it's only the first part of the code.
Also I believe heimdal can (or will be able to) use the LDAP attribute
"sambaNTPassword" as a arcfour-hmac-md5 kerberos key. I haven't tried
MIT KDC+DAL (or heimdal for that matter) but I guess that the raison
d'être of DAL being its possible use alongside future versions of samba,
it's likely to support the same feature.
Looking at Samba 4 sources, and reading around posts by
Andrew Tridgell, it seems the focus for Samba isn't to
interoperate with OpenLDAP and Heimdal (or MIT).
Instead, they're integrating some parts of Heimdal and rewriting
a lightweight LDAP server with as much functionality as it's
needed for ADS support.
Andrew says that 99% of sites just want to get the ActiveDirectory
domain controller to work and don't know or care anything about
full blown Kerberos and LDAP servers.
I think he's basically right, altough I'm one of those 1% users
who would be hit by this route of action.
I seem to remember some discussion about the fear of forking heimdal and
how the import of its code in samba4 was going to be temporary. That
position must have changed then.
In a related note, my hardest headache is renewing keys for users that
have home directories access via NFS4+krb5. We could not get
"gnome-kerberos" or "xscreensaver" to do it, so we keep a terminal
window open so that kinit can be run there. Am I missing something?
So someone actually got NFS4 + GSSAPI to work!!! Could you please
elaborate? I went through applying CITI's kernel and userland
patches, with very little luck.
I didn't have to apply any patches to get it working, although I had to
edit /etc/gssapi_mech.conf and change /usr/lib/libgssapi_krb5.so into
/usr/lib/libgssapi_krb5.so.2 (bug #151251). The rest seems to work out
of the box if you have the proper keys in /etc/krb5.keytab and
SECURE_NFS=y in /etc/sysinit/nfs.
It's only recently that I picked up the CITI kernel patches to see if
they would fix the frequent rpciod freezes I have been experiencing with
kernel 2.6.11-1.1369_FC4. And indeed, they seem to have fixed that problem.
Just out of curiousity, are there any further patches for nfs-utils that
are not included in FC3/4? If so what do they do?
Also is the new kernel keyring facility planned for FC5 inclusion?
Shouldn't that patch first be submitted to a kernel maintainer?
Last time I checked, outstanding NFSv4 patches were (slowly)
being included in official kernels through -mm.
Indeed, that's why I was asking. I guess I really meant to ask if anyone
knew if it was going to be mature enough to be included upstream before
FC5 was out.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
