[Samba] Upgrade from Samba 3.0.33 to 3.5.8 woes

[guido at lorenzutti.com.ar]

Did you update the schema on the ldap? Maybe you should. Im right know
doing it. I don't know how many changes are in the schema between 3.0.33
and 3.5.x. Im migrating from 3.0.24 to 3.2.X and if I don't upgrade the
schema the "password must change time" dosen't work.

What do you mean about the dc has a new time?

I was referring to the domain sid.

> The new DC has a new time.  We do use LDAP.  Which SID are you
> referring to?  The local SID is new on the new DC, but the domain sids
> are the same.
>
> On Tue, Mar 22, 2011 at 10:23 PM,  <guido at lorenzutti.com.ar> wrote:
>> The same happend to me.
>> But I didn't have the time to analize the problem. I solve it by
>> changing
>> the name of the server. Same ip, but new name and everything works now.
>>
>> It would be great to know if there is another workaround.
>>
>> Did you keep the sid of the pdc after the change?
>> Did you use ldap?
>>
>> Bye.
>>
>>> Greetings,
>>>
>>> I just did a major upgrade to our Samba infrastructure.
>>>
>>> I previously had a domain controller and share running 3.0.33 (on one
>>> box, one samba instance)
>>>
>>> I set up a new domain controller running 3.5.8, made that the PDC for
>>> our domain, and changed the (now former) domain controller running
>>> 3.0.33 to just be a member.  Additionally, we moved the IP from the
>>> old DC to the new DC (and subsequently gave the former DC, now just a
>>> member and file share a new IP)
>>>
>>> Now I am having some strange issues.
>>>
>>> Windows machines in our London office (which is connected via a tunnel
>>> between some Cisco ASA's from HQ to London) can no longer see the
>>> domain (which is at HQ) UNLESS we disable the Windows firewall on the
>>> workstations OR add exceptions to the firewall for the PDC.  Machines
>>> at HQ see the domain fine.  Now, the PDC has the SAME IP as the old
>>> domain.  So it's not like the rules would need to be any different
>>> anyway.  Frankly, I don't quite understand how this worked before -
>>> but it did!  Did something change between 3.0.x and 3.5.x which would
>>> cause this behavior and is there a fix?  I am hoping to not have to
>>> run through and change all of the firewalls on all of our workstations
>>> (especially since we can't do so via netlogon scripts etc as they
>>> won't see the domain!)  Worth noting, our machines all have an lmhosts
>>> file which tells them where to go for the domain, hence why we moved
>>> the IP from the old dc to the new dc.
>>>
>>> Second problem.. users can't access our file share (which was formerly
>>> the domain controller, now just a member) when connected via our VPN
>>> (a juniper ssl vpn).  The VPN drops them into the same network as if
>>> they are in the office -- and it works fine if you are in the office.
>>> Yet, if you come in via VPN you received "no logon servers available"
>>> errors.  Mac users connecting to the file share via SMB have no
>>> problem.  The following error is logged in smbd.log (redacted my
>>> specific names):
>>>
>>>  domain_client_validate: unable to validate password for user
>>> $username in domain $mydomain to Domain controller $mypdc. Error was
>>> NT_STATUS_UNSUCCESSFUL.
>>>
>>>
>>>
>>> Happy to provide any additional info.. I'm baffled!  All of this
>>> worked before without problems.
>>>
>>> Thanks,
>>> Ryan
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>
>>
>>
>