[Samba] Accessing external LDAP for classicupgrade

[Robert Moskowitz]

On 09/19/2015 06:13 AM, Rowland Penny wrote:
> On 19/09/15 10:32, Andrew Bartlett wrote:
>> On Fri, 2015-09-18 at 08:36 -0400, Robert Moskowitz wrote:
>>> On 09/18/2015 05:19 AM, Andrew Bartlett wrote:
>>>> On Thu, 2015-09-17 at 17:02 -0400, Robert Moskowitz wrote:
>>>>> I am reading the LDAP portion of:
>>>>>
>>>>> https://wiki.samba.org/index.php/Migrating_a_Samba_NT4_domain_to_
>>>>> a_Sa
>>>>> mba_AD_domain_%28classic_upgrade%29
>>>>>
>>>>> The second route may not work for me.  When I ran slapcat on the
>>>>> ClearOS
>>>>> system I got:
>>>>>
>>>>> # slapcat > ldap.backup.ldif
>>>>> 55fb2665 The first database does not allow slapcat; using the
>>>>> first
>>>>> available one (2)
>>>>>
>>>>> and very little in the backup file.
>>>>>
>>>>> So since the LDAP backend on the old server is only used for the
>>>>> classicupgrade, this looks interesting, but...
>>>>>
>>>>> What ldap.conf and smb.conf to I set up to retreive the
>>>>> information
>>>>> from
>>>>> the old LDAP backend host?  That is not clear.  I would have to
>>>>> start
>>>>> afresh (going to anyway) to see what a fresh system looks like
>>>>> with
>>>>> these two files.  On the ClearOS system, the ldap.conf says:
>>>>>
>>>>> # cat smb.ldap.conf
>>>>> # Please do not edit - this file is automatically generated.
>>>>>
>>>>> passdb backend = ldapsam:ldap://127.0.0.1
>>>>> ldap admin dn = cn=manager,ou=Internal,dc=home,dc=htt
>>>>> ldap group suffix = ou=Groups,ou=Accounts
>>>>> ldap idmap suffix = ou=Idmap
>>>>> ldap machine suffix = ou=Computers,ou=Accounts
>>>>> ldap passwd sync = No
>>>>> ldap suffix = dc=home,dc=htt
>>>>> ldap user suffix = ou=Users,ou=Accounts
>>>>> ldap connection timeout = 8
>>>>> ldap ssl = Off
>>>>>
>>>>> On my new AD, I would use the IP address of the old server (they
>>>>> have
>>>>> the same fqdn, but different DNS servers in different networks,
>>>>> but
>>>>> IP
>>>>> reachable).  Plus make sure the ldap port is open; it should be
>>>>> already.
>>>> Just change the 'passdb backend' line in the smb.conf to point to
>>>> your
>>>> old server.  In general we will only read it, but the backup
>>>> process is
>>>> there to make sure.
>>> So you are saying that on my Samba4 AD system, I setup ITS
>>> /etc/ldap/ldap.conf to be the same as my ClearOS, at least for the
>>> classicupdate, but to point the 'passdb backend' to it.  I will give
>>> that a test by deleteing (per the wiki) what the prior run of
>>> classicupdate did and try with this then report back.  Save the total
>>> rebuild after I learn how to also get the machines over. Profiles is
>>> 'just' a matter of rsyncing a LOT of files.
>>>
>> Samba does not read ldap.conf, and when we do the classicupgrade, we
>> force 'ldapsam:trusted=yes', so that we do not need nss_ldap
>> configured.  Instead, the only option we use is 'passdb backend' in the
>> smb.conf, and you just need to point that at the old server.

Yet adding that line to ldap.conf and I stopped getting the tls error.

>>
>> Andrew Bartlett
>>
>
> Hi Andrew, well, something is going wrong for the OP, he says he has 
> followed what is on the wiki, but his users are not making it to the 
> new AD DC.
>
> He followed the wiki and didn't get his users.
> He tried to use 'slapcat' to dump the database, it didn't work
> He tried again to 'classicupgrade' but this time added the ldap parts 
> to smb.conf (they were in 'include' lines that the upgrade ignored), 
> he got access denied.
> I suggested altering ldap.conf on the old server by removing the tls 
> lines and the access denied error is now gone (you sure that the 
> upgrade doesn't use ldap.conf?), but he still hasn't got any of his 
> old users in AD.
>
> Does the classicupgrade read ldap ? if so I have an idea how to 
> transfer the ldap info from the old server to the new one, but it will 
> mean that this line on the wiki: 'Install openLDAP (incl. headers and 
> libraries) on the new host' is going to need massive expansion.

Back.  Friday evening, I realized that I need to pass my admin password, 
that is why the ldapsearch works.  Think about it, why should the ldap 
pass all the user information to an anonymous query?  In fact I noted 
the following on the ClearOS server:

# cat clearos_anonymous.conf
# Please do not edit - this file is automatically generated.

# If you need to add your own custom access control rules, please do so in
# slapd.conf or a different include file.

# Read-only access to users and groups
#-------------------------------------

access to dn.base="dc=home,dc=htt"
     by * read stop

access to dn.subtree="ou=Accounts,dc=home,dc=htt" 
attrs=entry,objectClass,c,cn,description,facsimileTelephoneNumber,givenName,l,mail,member,mobile,o,ou,postalCode,postOfficeBox,roomNumber,sn,st,street,telephoneNumber,uid
     by * read stop

So the anon query will be limited.