[Samba] Upgrade from Samba 3.0.33 to 3.5.8 woes
guido at lorenzutti.com.ar
guido at lorenzutti.com.ar
Tue Mar 22 20:46:47 MDT 2011
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
>> 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?
>>> 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
>>> Happy to provide any additional info.. I'm baffled! All of this
>>> worked before without problems.
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba