[PATCH] Provisioning external LDAP server

[Oliver Liebel]

Am 17.02.2010 07:44, schrieb Andrew Bartlett:
> On Tue, 2010-02-16 at 22:07 -0500, Endi Sukma Dewata wrote:
>    
>> Andrew,
>>
>> ----- "Andrew Bartlett"<abartlet at samba.org>  wrote:
>>
>>      
>>> No, I don't like it being in smb.conf.  Firstly, it puts passwords in
>>> the config file, and it includes options that should strictly be
>>> determined by the realm (suffix).
>>>        
>> There are many instances where applications store passwords in the
>> configuration file. OpenLDAP has "rootpw" in slapd.conf.
keep in mind that we use cn=config with ol / s4  and _not_ slapd.conf 
any more,
and the passwords can be stored there in encrypted values (e.g. ssha), 
not cleartext.
>> FDS has
>> "nsslapd-rootpw" in dse.ldif. Samba has "secret" in secrets.ldb.
>> I think as long as it's well protected it should be ok.
>>      
cleartext passwords for admin-dns, even in "binary" files as 
secrets.tdb/ldb are always a potential risk.
>> But that issue aside, let's not put it in smb.conf. For creating the
>> backend let's use a separate config file, for example fedora-ds.conf.
>> You would use it with the create-backend tool:
>>
>> % setup/create-backend --config-file fedora-ds.conf
>>
>> The file would contain the following parameters:
>>
>> [backend]
>>      type           = fedora-ds
>>      home           = /var/lib/dirsrv/samba4
>>
>> [fedora-ds]
>>      admin dn       = cn=Manager,dc=samba,dc=example,dc=com
>>      admin password = secret
>>      suffix         = dc=samba,dc=example,dc=com
>>      user           = root
>>      ldap url       = ldapi://%2Fvar%2Flib%2Fdirsrv%2Fsamba4%2Fldapi
>>
>> After the backend is created, this file can be removed for security.
>>
>> The suffix needs to be specified because in this file we want to put
>> backend-specific parameters. I think realm belongs to smb.conf and I
>> don't think we want to specify it twice. This tool is not intended to
>> be used by most people, so I think it would be reasonable to expect
>> that people who create this file someone must know what they are
>> doing.
>>      
> I'm not so sure that's a safe assumption, but I like your proposal.
>
>    
>>> Even for your external LDAP server case, is there actually a need for
>>> the LDAPi socket to be in a different location?
>>>        
>> Not really, but if you run the backend on a separate machine you might
>> want to use LDAP or LDAPS instead of LDAPI, for example:
>>
>>     ldap url = ldap://ldap.example.com
>>
>> If you don't specify the ldap url it can default to ldapi://${home}/ldapi.
>>      
> Sure.  But do you need that for what you are doing?  I'm trying to avoid
> adding that option until someone gives me a reason why it's needed.
>
>    
>>> Once you move the password out of the smb.conf, then the username should
>>> move too.  We could leave the others in the smb.conf, but then it just
>>> encourages users to set them (and that's dangerous - we don't want
>>> variation here).
>>>        
>> To setup Samba frontend we will use another file, for example backend.conf.
>> You would use it with the provision tool:
>>
>> % setup/provision<provision parameters>  --backend-config backend.conf
>>
>> The file would contain the following parameters:
>>
>> [backend]
>>      type           = external fedora-ds
>>
>> [fedora-ds]
>>      admin dn       = cn=Manager,dc=samba,dc=example,dc=com
>>      admin password = secret
>>      ldap url       = ldapi://%2Fvar%2Flib%2Fdirsrv%2Fsamba4%2Fldapi
>>
>> The provision tool will figure out the suffix from the realm. Once it's
>> done you can remove this file for security. Samba will still have the
>> password in the secrets.ldb.
>>
>> Since the fedora-ds.conf and backend.conf contain password, it is suggested
>> above that we remove the files afterward. But wouldn't this defeat the
>> purpose of creating the files in the first place?
>>      
> The purpose of creating the files is to avoid typos on command lines,
> and putting passwords on the command lines.
>
> This looks like a reasonable proposal.
>
> Andrew Bartlett
>
>