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, <[email protected]> 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 >>> >> >> >> > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
