Basically a windows client can't authenticate against a Kerberos server
*and* get user information out LDAP without using AD. You can
authenticate against Kerberos and have local user accounts or you can
have user accounts in LDAP and use some other authentication mechanism.
The way I'm doing it is storing user's Windows passwords in LDAP as
sambaNTPassword and storing *nix/OS X passwords in Kerberos. To get
around having different passwords for the different architectures you
can write a script that will be the change password script in samba and
a replacement for passwd under *nix. This script would add/change the
password in both LDAP and Kerberos keeping them synced.
FW is referring to such a perl script using Authen::Krb5,
Crypt::SmbHash, and Net::LDAP.
The Kerberos options you see in Samba are only for having Samba
authenticate against an AD server.
There are some things in the works for going the other way if you're
using Heimdal (see the archive), but I have no experience with Heimdal
or this solution.
On Mon, 2005-06-06 at 10:03 -0700, Jeff Block wrote:> I'm a little confused on one section here... Where are your passwords
being
> stored? kerberos? If so, how does samba look there? What is the
> significance of the {SASL}USER at REALM in LDAP? Is there another password
> store that you are syncing with krb?
>
> Sorry for my ignorance here but after hours and hours of trying different
> things, I'm unable to use my kerberos backend with samba.
>
> Thanks in advance.
>
>
> FM Wrote:
>
> >Hello,
> >My setup :
> >Windows stations
> >SAMBA3+OPENLDAP 2.2.x +KERBEROS (MIT)
> >
> >All users (posix and ldap) are in Openldap.
> >All my ldap password are : {SASL}USER at REALM
> >I use saslauthd so I can connect to ldap using simplebind with password
> >in KERBEROS
> >this password CANNOT be changed (denied by the slapd.access.conf file)
> >
> >Samba cannot use MIt kerberos for the password so my little trick :
> >I create a perl scrip using Authen::Krb5::Admin that use un keytab for
> >authentifiaction :krb5_update_pwd.pl
> >
> >in the smb.conf :
> > ldap passwd sync = No
> > unix password sync = Yes
> > passwd program = /usr/local/sbin/krb5_update_pwd.pl -u %u
> >%n\n *passwd:*all*authentication*tokens*updated*successfully*
> > passwd chat = *Password:* %n\n *Again:* %n\n *Changed*
> >
> >So when Windows users change their password(from the change password
> >option in Windows), SAMBA called /krb5_update_pwd.pl that also update
> >the KERBEROS password.
> >
> >Linux users just have to use :
> >smbpasswd -r PDC_SERVER
> >That command update SAMBA password and again it called
> >/krb5_update_pwd.pl to sync the kerberos password
> >
> >I know there are some short comings (password policies for example).
But
> >it's the closer i get :-)
> >
> >Hope this can help :-)
> >
> >
> >
> Ti Leggett wrote:
> > Let me rephrase a bit. Is there a way to use Samba as a PDC with an
LDAP
> > backend and use pam_smbpass to keep the passwords sync'd between
the
> > Kerberos side and the Samba side? That way the Windows clients join
the
> > domain using only the LDAP information not knowing about the Kerberos
> > side of things?
> >
> > I just removed the Kerberos information from my Windows client and
tried
> > only using, as far as I can tell, the LDAP information and the client
> > still comes back saying the user name is unknown.
> >
> > On Sat, 2005-04-23 at 08:07 -0500, Ti Leggett wrote:
> >
> >>Ok, so I'm just trying to figure out my options here. I can:
> >>
> >>- Use local accounts and local passwords
> >>- Use Kerberos for authentication, but only with local user
accounts
> >>- Use a Samba PDC with and LDAP backend for accounts and password
if and
> >>only if the windows clients are not bound to a Kerberos realm
> >>
> >>Is this correct? In the third case, let's say I have a way to
sync
> >>Kerberos passwords and LDAP sambaNTPasswords. Shouldn't it work
then?
> >>
> >>Or what am I missing? I know I can't create an AD domain, but
I'm not
> >>trying to. AD is combination of a lot more than just Kerberos and
LDAP.
> >>
> >>I'm curios how Apple does what seems to be just this with their
> >>OpenDirectory, which is only MIT Kerberos, OpenLDAP, Cyrus SASL,
and
> >>Samba 3.0 (at least they claim it's only this).
> >>
> >>
> >>On Fri, 2005-04-22 at 18:52 -0500, Franco "Sensei" wrote:
> >>
> >>>Ti Leggett wrote:
> >>>
> >>>>I've been searching and researching this and I
can't seem to find the
> >>>>answers I'm looking for. I'd like to setup a Samba
PDC that Windows
> >>>>clients will join. The PDC will use an LDAP backend to get
authorization
> >>>>information (username, home directory, etc). The
authentication portion
> >>>>is handled by an MIT Kerberos KDC. I think I'm real
close to having it
> >>>>all together but I'm not sure. I have the Windows
client setup to point
> >>>>at my KDC so authentication *should* be coming from there
once the
> >>>>authorization portion is going.
> >>>
> >>>Hehehe, it's been a year trying to do that... but no way!
I'm sorry to
> >>>tell you, but what you want is a replacement of AD... in no way
windows
> >>>will know about ldap and mit, without an AD domain.
> >>>
> >>>
> >>>>So first question is, are sambaLMPassword and
sambaNTPassword still
> >>>>needed in LDAP for each user?
> >>>>
> >>>>Here's the output from ksetup /dumpstate:
> >>>>
> >>>>Machine is not configured to log on to an external KDC.
Probably a
> >>>>workgroup member
> >>>>EXAMPLE.COM:
> >>>> kdc = <kdc1 server>
> >>>> kdc = <kdc2 server>
> >>>> kpasswd = <kpasswd server>
> >>>> Realm Flags = 0x0 none
> >>>>No user mappings defined.
> >>>
> >>>Users must be somewhere to get HKEY_LOCAL* work... and they
should be
> >>>local users (the MIT-KDC authentication works this way).
> >>>
> >>>
> >>>>Second, here's what I have in LDAP so far:
> >>>>[...]
> >>>>I've done a smbpasswd -w <hidden samba_server
password>
> >>>>
> >>>>I can do a net getlocalsid and it will get the correct SID
out of LDAP.
> >>>
> >>>Correct.
> >>>
> >>>
> >>>>However, when I try to join my Windows client to the
EXAMPLE.COM domain,
> >>>>I can see the ldap queries happening, but the Windows
client reports an
> >>>>invalid username.
> >>>
> >>>Yes. Active Directory is not there... and it wants AD. In no
way you can
> >>>fake AD, even though it's kerberos, ldap and smb +
natural-flavours...
> >>>
> >>
> >>
> >
>
>