[Samba] Samba and Heimdal Kerberos V Authentication
Gémes Géza
geza at kzsdabas.sulinet.hu
Mon Dec 4 22:48:06 GMT 2006
Matt Proud írta:
> Gemes,
>
> Thank you. I had seen this link a while ago. I had wanted to avoid
> placing authentication data in the LDAP database, but I guess that
> this could work. Have you done this yourself? Do you have any useful
> comments or suggestions to make?
>
> That schema file referenced in this document does not seem to be
> available. Where can I find it?
>
> Best,
>
> Matt
>
> On 11/29/06, Gémes Géza <geza at kzsdabas.sulinet.hu> wrote:
>> Matt Proud írta:
>> > Hello,
>> >
>> > I maintain a network of numerous Linux workstations, several Apples,
>> > and a few Windows machines. The Apples and Windows XP machines already
>> > grab shared data via Samba and the remaining data is exported to the
>> > Linux machines via NFS.
>> >
>> > I am in the process of migrating the existing authentication system
>> > from XYZ123 to Kerberos and going to place user data---with the
>> > exception of passwords into OpenLDAP.
>> >
>> > I am curious whether it is possible to have Samba authenticate against
>> > Kerberos as a password backend, particularly with the Heimdal
>> > implementation. I really am not much of a Windows guru and try to
>> > avoid the OS as much as possible; but I have gathered that from 2000
>> > onwards it has supported Kerberos V for authentication. Would this
>> > mean that the winbind backend could be used to talk to the Kerberos
>> > server?
>> >
>> > I really want to avoid having to write any custom scripts or wrappers
>> > to synchronize passwords between Samba and Kerberos.
>> >
>> > What are everybody's thoughts?
>> >
>> > Thank you,
>> >
>> > Matt
>> Recommended reading:
>> http://www.pdc.kth.se/heimdal/heimdal.html#Using-LDAP-to-store-the-database
>>
>>
>> Cheers
>>
>> Geza
>>
>>
Yes I use it with ~1000 users, and it's working like charm, you just
have to take care of the ACLs of passwords stored on LDAP as stated on
Samba and Heimdal documentations, also if you want nonsasl binds you may
want to set the userPassword attributes to
{SASL}theusersuid at YOUR.KERBEROS.REALM. I've attached my
/usr/lib/sasl2/slapd.conf, /etc/default/saslauthd (I use debian), and
hdb.schema (I've found it googleing).
Good Luck!
Geza
-------------- next part --------------
# Definitions for a Kerberos V KDC schema
#
# $Id: hdb.schema,v 1.3 2005/04/25 17:33:40 lha Exp $
#
# This version is compatible with OpenLDAP 1.8
#
# OID Base is iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) padl(5322) kdcSchema(10)
#
# Syntaxes are under 1.3.6.1.4.1.5322.10.0
# Attributes types are under 1.3.6.1.4.1.5322.10.1
# Object classes are under 1.3.6.1.4.1.5322.10.2
# Syntax definitions
#krb5KDCFlagsSyntax SYNTAX ::= {
# WITH SYNTAX INTEGER
#-- initial(0), -- require as-req
#-- forwardable(1), -- may issue forwardable
#-- proxiable(2), -- may issue proxiable
#-- renewable(3), -- may issue renewable
#-- postdate(4), -- may issue postdatable
#-- server(5), -- may be server
#-- client(6), -- may be client
#-- invalid(7), -- entry is invalid
#-- require-preauth(8), -- must use preauth
#-- change-pw(9), -- change password service
#-- require-hwauth(10), -- must use hwauth
#-- ok-as-delegate(11), -- as in TicketFlags
#-- user-to-user(12), -- may use user-to-user auth
#-- immutable(13) -- may not be deleted
# ID { 1.3.6.1.4.1.5322.10.0.1 }
#}
#krb5PrincipalNameSyntax SYNTAX ::= {
# WITH SYNTAX OCTET STRING
#-- String representations of distinguished names as per RFC1510
# ID { 1.3.6.1.4.1.5322.10.0.2 }
#}
# Attribute type definitions
attributetype ( 1.3.6.1.4.1.5322.10.1.1
NAME 'krb5PrincipalName'
DESC 'The unparsed Kerberos principal name'
EQUALITY caseExactIA5Match
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.5322.10.1.2
NAME 'krb5KeyVersionNumber'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.3
NAME 'krb5MaxLife'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.4
NAME 'krb5MaxRenew'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.5
NAME 'krb5KDCFlags'
EQUALITY integerMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.6
NAME 'krb5EncryptionType'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.7
NAME 'krb5ValidStart'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5322.10.1.8
NAME 'krb5ValidEnd'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5322.10.1.9
NAME 'krb5PasswordEnd'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
# this is temporary; keys will eventually
# be child entries or compound attributes.
attributetype ( 1.3.6.1.4.1.5322.10.1.10
NAME 'krb5Key'
DESC 'Encoded ASN1 Key as an octet string'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
attributetype ( 1.3.6.1.4.1.5322.10.1.11
NAME 'krb5PrincipalRealm'
DESC 'Distinguished name of krb5Realm entry'
SUP distinguishedName )
attributetype ( 1.3.6.1.4.1.5322.10.1.12
NAME 'krb5RealmName'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
# Object class definitions
objectclass ( 1.3.6.1.4.1.5322.10.2.1
NAME 'krb5Principal'
SUP top
AUXILIARY
MUST ( krb5PrincipalName )
MAY ( cn $ krb5PrincipalRealm ) )
objectclass ( 1.3.6.1.4.1.5322.10.2.2
NAME 'krb5KDCEntry'
SUP krb5Principal
AUXILIARY
MUST ( krb5KeyVersionNumber )
MAY ( krb5ValidStart $ krb5ValidEnd $ krb5PasswordEnd $
krb5MaxLife $ krb5MaxRenew $ krb5KDCFlags $
krb5EncryptionType $ krb5Key ) )
objectclass ( 1.3.6.1.4.1.5322.10.2.3
NAME 'krb5Realm'
SUP top
AUXILIARY
MUST ( krb5RealmName ) )
-------------- next part --------------
# This needs to be uncommented before saslauthd will be run automatically
START=yes
# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"
MECHANISMS="kerberos5"
More information about the samba
mailing list