Thanks Louis, it seems the DNS updates were working even with the nsswitch.conf I had, but only for machines that I manually joined to the new AD Domain. I checked the ones I didn't join manually and they aren't proper members of the domain anymore. If I try to logon with anything but the last (cached) user account on a Win7 machine I get: "The trust relationship between this workstation and the primary domain failed". I am unsure what has changed. The classicupgrade worked flawless regarding the windows machines' domain membership before. I redid it today, to no avail. Got a new backup from LDAP from the still productive Samba 3.4.3 PDC (running on Debian Lenny) and redid the classicupgrade again...still the trust relationship fails. Is there an explanation for this? I tested with a WinXP machine as well and get the same error. Both the Win7 and WinXP are proper members of the NT-4 domain. I made a backup of the domain from the Debian Lenny, did the classicupgrade from the backup (on the AD DC to be, a Debian Jessie), switched the IP adresses of the Win7 and WinXP to the testing environment and they produce the beforementioned error. Manually joining to them new domain is no problem. The thing that surprises me most, is that it worked before with this testing setup. Rowland, regarding the naming conventions for NETBIOS-Domainname and Kerberos Realm, we will rename them if we have to manually join the machines to the domain. If it is possible to circumvent that, we'll go with the dot in the NETBIOS name. We recognize it's not ideal, but renaming would mean rejoining about a hundred machines and reestablishing their locally saved user profiles. On 11 April 2015 at 22:37, Rowland Penny <rowlandpenny at googlemail.com> wrote:> On 11/04/15 20:38, Timo Altun wrote: > >> Hi and thank you for the answers! >> >> How do I setup the clients to do their own updates? I do not recall doing >> anything on the windows client side to setup the automatic dns updates. >> > > You can turn off the windows clients ability to update their own dns > records, if you don't know about it then it is doubtful this is your > problem. > > The linux wheezy clients with samba 3.6.6. actually never managed to >> automatically update dns during domain join, not even in the test >> environment. I settled for manually adding those to the dns, as they're >> just a handful. >> > > This is one of the reasons why I run bind9 and a dhcp server on the AD DC, > the AD DC already has the clients dns records before the join. > > >> One of my priorities during domain provision (during classicupgrade in >> fact), was to not have to manually join the windows clients to the new >> domain. This works with this configuration. The old NT-4 Domain also had >> that dot in MAYWEG.NET <http://MAYWEG.NET>. This is also what I was >> referring to when I said, the windows clients do not "notice" the change. I >> knew that there's no "automatic" going back to the old NT-4 domain, once >> they've seen the new AD DC (Rowland enlightened me a couple of days ago). >> > > Have a look here: https://support.microsoft.com/en-us/kb/909264 > > especially under the heading 'Domain names' > > Names can contain a period (.). However, the name cannot start with a > period. The use of non-DNS names with periods is allowed in Microsoft > Windows NT. However, periods should not be used in Active Directory > domains. If you are upgrading a domain whose NetBIOS name contains a > period, change the name by migrating the domain to a new domain structure. > Do not use periods in new NetBIOS domain names. > > >> Is there maybe a deeper logging level I can turn on somewhere? Or is >> there a log on the windows client side? >> >> > You could have a look in the event log on a client that isn't updating its > records, is there anything in any of the samba logs ? > > Have you looked at this wiki page: https://wiki.samba.org/index. > php/DNS_Backend_BIND > > Rowland > > Greetings, >> Timo >> >> >> On 11 April 2015 at 20:29, Rowland Penny <rowlandpenny at googlemail.com >> <mailto:rowlandpenny at googlemail.com>> wrote: >> >> On 11/04/15 18:54, Timo Altun wrote: >> >> Good evening, >> >> unfortunately one problem emerged during the change from my >> testing environment to a small portion of the live environment. >> The automatic dns updates of the windows clients do not seem >> to work in the live environment. I changed the AD DC IP from >> another subnet to 192.168.111.90, without reprovisioning. >> Everything else seems to work fine though (e.g. domain joins, >> shares and DNS forwarding, looking up manually added entries). >> I could also add entries manually with samba-tool dns add, but >> keeping in mind that it worked in the other subnet I would >> like to avoid that. >> My DNS Backend is BIND 9.9.5 from the Debian Wheezy sources. >> As I don't receive any real error messages (looked in syslog, >> messages, /var/log/samba/log.smbd) I don't have a clue where >> the problem is. Maybe somebody has an idea?! >> >> The startup seems fine in the log: >> Apr 11 18:53:42 server06 named[4141]: starting BIND >> 9.9.5-9-Debian -f -u bind >> Apr 11 18:53:42 server06 named[4141]: built with >> '--prefix=/usr' '--mandir=/usr/share/man' >> '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' >> '--localstatedir=/var' '--enable-threads' '--enable-largefile' >> '--with-libtool' '--enable-shared' '--enable-static' >> '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' >> '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' >> '--enable-rrl' '--enable-filter-aaaa' >> 'CFLAGS=-fno-strict-aliasing -fno-delete-null-pointer-checks >> -DDIG_SIGCHASE -O2' >> Apr 11 18:53:42 server06 named[4141]: >> ---------------------------------------------------- >> Apr 11 18:53:42 server06 named[4141]: BIND 9 is maintained by >> Internet Systems Consortium, >> Apr 11 18:53:42 server06 named[4141]: Inc. (ISC), a non-profit >> 501(c)(3) public-benefit >> Apr 11 18:53:42 server06 named[4141]: corporation. Support and >> training for BIND 9 are >> Apr 11 18:53:42 server06 named[4141]: available at >> https://www.isc.org/support >> Apr 11 18:53:42 server06 named[4141]: >> ---------------------------------------------------- >> Apr 11 18:53:42 server06 named[4141]: adjusted limit on open >> files from 4096 to 1048576 >> Apr 11 18:53:42 server06 named[4141]: found 4 CPUs, using 4 >> worker threads >> Apr 11 18:53:42 server06 named[4141]: using 4 UDP listeners >> per interface >> Apr 11 18:53:42 server06 named[4141]: using up to 4096 sockets >> Apr 11 18:53:42 server06 named[4141]: loading configuration >> from '/etc/bind/named.conf' >> Apr 11 18:53:42 server06 named[4141]: reading built-in trusted >> keys from file '/etc/bind/bind.keys' >> Apr 11 18:53:42 server06 named[4141]: using default UDP/IPv4 >> port range: [1024, 65535] >> Apr 11 18:53:42 server06 named[4141]: using default UDP/IPv6 >> port range: [1024, 65535] >> Apr 11 18:53:42 server06 named[4141]: listening on IPv4 >> interface lo, 127.0.0.1#53 >> Apr 11 18:53:42 server06 named[4141]: listening on IPv4 >> interface eth0, 192.168.111.90#53 >> Apr 11 18:53:42 server06 named[4141]: generating session key >> for dynamic DNS >> Apr 11 18:53:42 server06 named[4141]: sizing zone task pool >> based on 5 zones >> Apr 11 18:53:42 server06 named[4141]: Loading 'AD DNS Zone' >> using driver dlopen >> Apr 11 18:53:42 server06 named[4141]: samba_dlz: started for >> DN DC=intranet,DC=mayweg,DC=net >> Apr 11 18:53:42 server06 named[4141]: samba_dlz: starting >> configure >> Apr 11 18:53:42 server06 named[4141]: samba_dlz: configured >> writeable zone '111.168.192.in-addr.arpa' >> Apr 11 18:53:42 server06 named[4141]: samba_dlz: configured >> writeable zone 'intranet.mayweg.net >> <http://intranet.mayweg.net> <http://intranet.mayweg.net>' >> >> Apr 11 18:53:42 server06 named[4141]: samba_dlz: configured >> writeable zone '_msdcs.intranet.mayweg.net >> <http://msdcs.intranet.mayweg.net> >> <http://msdcs.intranet.mayweg.net>' >> Apr 11 18:53:42 server06 named[4141]: set up managed keys zone >> for view _default, file 'managed-keys.bind' >> [...] >> Apr 11 18:53:42 server06 named[4141]: command channel >> listening on 127.0.0.1#953 >> Apr 11 18:53:42 server06 named[4141]: command channel >> listening on ::1#953 >> Apr 11 18:53:42 server06 named[4141]: managed-keys-zone: >> loaded serial 3 >> Apr 11 18:53:42 server06 named[4141]: zone 0.in-addr.arpa/IN: >> loaded serial 1 >> Apr 11 18:53:42 server06 named[4141]: zone >> 127.in-addr.arpa/IN: loaded serial 1 >> Apr 11 18:53:42 server06 named[4141]: zone localhost/IN: >> loaded serial 2 >> Apr 11 18:53:42 server06 named[4141]: zone >> 255.in-addr.arpa/IN: loaded serial 1 >> Apr 11 18:53:42 server06 named[4141]: all zones loaded >> Apr 11 18:53:42 server06 named[4141]: running >> >> The only thing I find a bit strange is "command channel >> listening on ::1#953" instead of the actual IPv4 address. >> My smb.conf on the AD DC can be found in the e-mail before. >> Here is the rest: >> >> *krb5.conf:* >> [libdefaults] >> default_realm = INTRANET.MAYWEG.NET >> <http://INTRANET.MAYWEG.NET> <http://INTRANET.MAYWEG.NET> >> >> dns_lookup_realm = false >> dns_lookup_kdc = true >> * >> * >> *named.conf:* >> include "/etc/bind/named.conf.options"; >> include "/etc/bind/named.conf.local"; >> include "/etc/bind/named.conf.default-zones"; >> include "/var/lib/samba/private/named.conf"; >> >> *named.conf.default-zones:* >> // prime the server with knowledge of the root servers >> zone "." { >> type hint; >> file "/etc/bind/db.root"; >> }; >> >> // be authoritative for the localhost forward and reverse >> zones, and for >> // broadcast zones as per RFC 1912 >> >> zone "localhost" { >> type master; >> file "/etc/bind/db.local"; >> }; >> >> zone "127.in-addr.arpa" { >> type master; >> file "/etc/bind/db.127"; >> }; >> >> zone "0.in-addr.arpa" { >> type master; >> file "/etc/bind/db.0"; >> }; >> >> zone "255.in-addr.arpa" { >> type master; >> file "/etc/bind/db.255"; >> }; >> >> *named.conf.options:* >> options { >> directory "/var/cache/bind"; >> >> forwarders { >> 192.168.111.79; >> }; >> >> dnssec-validation no; >> >> auth-nxdomain no; # conform to RFC1035 >> listen-on { any; }; >> tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab"; >> }; >> * >> * >> *named.conf.local:* >> //empty >> >> */var/lib/samba/private/named.conf:* >> dlz "AD DNS Zone" { >> # For BIND 9.9.x >> database "dlopen >> /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so"; >> }; >> >> I also checked the permissions on /etc/krb5.keytab and >> /var/lib/samba/private/dns.keytab. Both should be accessible >> by bind and samba. >> >> Greetings, >> Timo >> >> >> Your files are the same as mine and mine works (mind you I use >> dhcp running on the first DC), If something does go wrong It shows >> errors in syslog. I take it that the clients are set up to do >> their own updates. >> >> The '953' number you are worrying about is the command channel >> listening on the ipv6 localhost address. >> >> I am not entirely sure you can use the DNS server on an AD DC for >> more than one domain, it usually just updates the one forward >> zone. I am still not happy with the workgroup with a dot in it. >> >> Rowland >> >> >> Rowland >> >> -- 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 >
On 13/04/15 16:13, Timo Altun wrote:> Thanks Louis, it seems the DNS updates were working even with the > nsswitch.conf I had, but only for machines that I manually joined to > the new AD Domain. > > I checked the ones I didn't join manually and they aren't proper > members of the domain anymore. If I try to logon with anything but the > last (cached) user account on a Win7 machine I get: "The trust > relationship between this workstation and the primary domain failed". > > I am unsure what has changed. The classicupgrade worked flawless > regarding the windows machines' domain membership before. I redid it > today, to no avail. Got a new backup from LDAP from the still > productive Samba 3.4.3 PDC (running on Debian Lenny) and redid the > classicupgrade again...still the trust relationship fails. > > Is there an explanation for this? I tested with a WinXP machine as > well and get the same error. > Both the Win7 and WinXP are proper members of the NT-4 domain. I made > a backup of the domain from the Debian Lenny, did the classicupgrade > from the backup (on the AD DC to be, a Debian Jessie), switched the IP > adresses of the Win7 and WinXP to the testing environment and they > produce the beforementioned error. Manually joining to them new domain > is no problem. > > The thing that surprises me most, is that it worked before with this > testing setup. > > Rowland, regarding the naming conventions for NETBIOS-Domainname and > Kerberos Realm, we will rename them if we have to manually join the > machines to the domain. If it is possible to circumvent that, we'll go > with the dot in the NETBIOS name. We recognize it's not ideal, but > renaming would mean rejoining about a hundred machines and > reestablishing their locally saved user profiles. >I understand where you are coming from, it is a lot of work to go around and rejoin such a lot of machines, but I just thought that I should point out the possible pitfalls of using a workgroup name with a dot in it. I personally would get about 10-20 machines connected to the AD domain and see how you go, if you have no problems, then great, connect the rest and let us know that it does work. However if it doesn't work and you get problems, you will have less machines to sort out and again, please let us know this and what problems you have had, I will then add something to the wiki. Rowland
L.P.H. van Belle
2015-Apr-14 06:59 UTC
[Samba] Trust relationship fails after classicupgrade
Hai Timo, To overcome the same problem, im doing the following. The old samba 3.4-3.6 based on ldap ( same here debian lenny/squeeze ), im keeping intact. The new samba 4 AD domain, has (policy based) drive mappings to the old domain. Im having 2 domains now, a bit more work, but zero down time. The new domain has a new domainname, new sid, all is new created, because i just dont want old references in my new domain. This also save you from "strange" problemens in samba 4. And after 8 Years, a new clean domain can be nice.. I've exported all my users (without password) and imported them in samba 4. First time at login, users must set the same password as on the old server. and now you can map a user to OLDDOMAIN\%username% in the policies to get the shares on the old server. And now i can change slowly my computers, so everyone is getting a new clean setup. server and computer profiles, all nicely and clean.. yes more work now, but in the long run, less. when all users, groups computers, policies etc are done, then im migriting the servers. in the end, im only migrating 2 server, my file server, and my database server. these i cant reinstall, all others are clean installed. This is just a suggest, and yes for now more work, but it will pay back in the long run. Greetz, Louis>-----Oorspronkelijk bericht----- >Van: rowlandpenny at googlemail.com >[mailto:samba-bounces at lists.samba.org] Namens Rowland Penny >Verzonden: maandag 13 april 2015 17:34 >Aan: sambalist >Onderwerp: Re: [Samba] Trust relationship fails after classicupgrade > >On 13/04/15 16:13, Timo Altun wrote: >> Thanks Louis, it seems the DNS updates were working even with the >> nsswitch.conf I had, but only for machines that I manually joined to >> the new AD Domain. >> >> I checked the ones I didn't join manually and they aren't proper >> members of the domain anymore. If I try to logon with >anything but the >> last (cached) user account on a Win7 machine I get: "The trust >> relationship between this workstation and the primary domain failed". >> >> I am unsure what has changed. The classicupgrade worked flawless >> regarding the windows machines' domain membership before. I redid it >> today, to no avail. Got a new backup from LDAP from the still >> productive Samba 3.4.3 PDC (running on Debian Lenny) and redid the >> classicupgrade again...still the trust relationship fails. >> >> Is there an explanation for this? I tested with a WinXP machine as >> well and get the same error. >> Both the Win7 and WinXP are proper members of the NT-4 >domain. I made >> a backup of the domain from the Debian Lenny, did the classicupgrade >> from the backup (on the AD DC to be, a Debian Jessie), >switched the IP >> adresses of the Win7 and WinXP to the testing environment and they >> produce the beforementioned error. Manually joining to them >new domain >> is no problem. >> >> The thing that surprises me most, is that it worked before with this >> testing setup. >> >> Rowland, regarding the naming conventions for NETBIOS-Domainname and >> Kerberos Realm, we will rename them if we have to manually join the >> machines to the domain. If it is possible to circumvent >that, we'll go >> with the dot in the NETBIOS name. We recognize it's not ideal, but >> renaming would mean rejoining about a hundred machines and >> reestablishing their locally saved user profiles. >> > >I understand where you are coming from, it is a lot of work to >go around >and rejoin such a lot of machines, but I just thought that I should >point out the possible pitfalls of using a workgroup name with >a dot in >it. I personally would get about 10-20 machines connected to the AD >domain and see how you go, if you have no problems, then >great, connect >the rest and let us know that it does work. However if it doesn't work >and you get problems, you will have less machines to sort out >and again, >please let us know this and what problems you have had, I will >then add >something to the wiki. > >Rowland >-- >To unsubscribe from this list go to the following URL and read the >instructions: https://lists.samba.org/mailman/options/samba > >
Hey Louis,
thanks for the answer! That sounds like a viable route to go. Of course I'd
prefer doing the classicupgrade and having the trust relationship still
intact. It did work this way at some point during testing, that's why I
find it hard to accept that I have to circumvent the problem like this.
Did somebody else lose trust relationships after classicupgrade and found a
way to restore them? I didn't find much information on this on
Google...only advice is to rejoin the machines to the new domain...I know
that works.
Maybe I still have some errors or missing parameters in my configs on the
AD DC? As always, any hints where this problem might originate from are
highly appreciated!
Next I'll probably try to purge all samba from the AD DC and try again.
Greetings,
Timo
*smb.conf*
[global]
workgroup = MAYWEG.NET
realm = INTRANET.MAYWEG.NET
netbios name = SERVER06
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind,
ntp_signd, kcc, dnsupdate
idmap_ldb:use rfc2307 = yes
[netlogon]
path = /var/lib/samba/sysvol/intranet.mayweg.net/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
*krb5.conf*
[libdefaults]
default_realm = INTRANET.MAYWEG.NET
dns_lookup_realm = false
dns_lookup_kdc = true
hosts
127.0.0.1 localhost localhost.localdomain
192.168.11.90 server06.intranet.mayweg.net server06 krb
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
*resolv.conf*
nameserver 127.0.0.1
domain intranet.mayweg.net
*named.conf*
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/var/lib/samba/private/named.conf";
*named.conf.default-zones*
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
*named.conf.options*
options {
directory "/var/cache/bind";
dnssec-validation no;
auth-nxdomain no; # conform to RFC1035
listen-on { any; };
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
};
/var/lib/samba/named.conf
dlz "AD DNS Zone" {
# For BIND 9.9.x
database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";
};
On 14 April 2015 at 08:59, L.P.H. van Belle <belle at bazuin.nl> wrote:
> Hai Timo,
>
> To overcome the same problem, im doing the following.
>
> The old samba 3.4-3.6 based on ldap ( same here debian lenny/squeeze ), im
> keeping intact.
> The new samba 4 AD domain, has (policy based) drive mappings to the old
> domain.
> Im having 2 domains now, a bit more work, but zero down time.
>
> The new domain has a new domainname, new sid, all is new created, because
> i just dont want old
> references in my new domain. This also save you from "strange"
problemens
> in samba 4.
> And after 8 Years, a new clean domain can be nice..
>
> I've exported all my users (without password) and imported them in
samba 4.
> First time at login, users must set the same password as on the old server.
> and now you can map a user to OLDDOMAIN\%username% in the policies to get
> the shares on the old server.
>
> And now i can change slowly my computers, so everyone is getting a new
> clean setup.
> server and computer profiles, all nicely and clean.. yes more work now,
> but in the long run, less.
> when all users, groups computers, policies etc are done, then im migriting
> the servers.
> in the end, im only migrating 2 server, my file server, and my database
> server.
> these i cant reinstall, all others are clean installed.
>
> This is just a suggest, and yes for now more work, but it will pay back in
> the long run.
>
>
> Greetz,
>
> Louis
>
> >-----Oorspronkelijk bericht-----
> >Van: rowlandpenny at googlemail.com
> >[mailto:samba-bounces at lists.samba.org] Namens Rowland Penny
> >Verzonden: maandag 13 april 2015 17:34
> >Aan: sambalist
> >Onderwerp: Re: [Samba] Trust relationship fails after classicupgrade
> >
> >On 13/04/15 16:13, Timo Altun wrote:
> >> Thanks Louis, it seems the DNS updates were working even with the
> >> nsswitch.conf I had, but only for machines that I manually joined
to
> >> the new AD Domain.
> >>
> >> I checked the ones I didn't join manually and they aren't
proper
> >> members of the domain anymore. If I try to logon with
> >anything but the
> >> last (cached) user account on a Win7 machine I get: "The
trust
> >> relationship between this workstation and the primary domain
failed".
> >>
> >> I am unsure what has changed. The classicupgrade worked flawless
> >> regarding the windows machines' domain membership before. I
redid it
> >> today, to no avail. Got a new backup from LDAP from the still
> >> productive Samba 3.4.3 PDC (running on Debian Lenny) and redid the
> >> classicupgrade again...still the trust relationship fails.
> >>
> >> Is there an explanation for this? I tested with a WinXP machine as
> >> well and get the same error.
> >> Both the Win7 and WinXP are proper members of the NT-4
> >domain. I made
> >> a backup of the domain from the Debian Lenny, did the
classicupgrade
> >> from the backup (on the AD DC to be, a Debian Jessie),
> >switched the IP
> >> adresses of the Win7 and WinXP to the testing environment and they
> >> produce the beforementioned error. Manually joining to them
> >new domain
> >> is no problem.
> >>
> >> The thing that surprises me most, is that it worked before with
this
> >> testing setup.
> >>
> >> Rowland, regarding the naming conventions for NETBIOS-Domainname
and
> >> Kerberos Realm, we will rename them if we have to manually join
the
> >> machines to the domain. If it is possible to circumvent
> >that, we'll go
> >> with the dot in the NETBIOS name. We recognize it's not ideal,
but
> >> renaming would mean rejoining about a hundred machines and
> >> reestablishing their locally saved user profiles.
> >>
> >
> >I understand where you are coming from, it is a lot of work to
> >go around
> >and rejoin such a lot of machines, but I just thought that I should
> >point out the possible pitfalls of using a workgroup name with
> >a dot in
> >it. I personally would get about 10-20 machines connected to the AD
> >domain and see how you go, if you have no problems, then
> >great, connect
> >the rest and let us know that it does work. However if it doesn't
work
> >and you get problems, you will have less machines to sort out
> >and again,
> >please let us know this and what problems you have had, I will
> >then add
> >something to the wiki.
> >
> >Rowland
> >--
> >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
>
Reasonably Related Threads
- Trust relationship fails after classicupgrade
- Dynamic DNS Updates not working. samba_dnsupdate : RuntimeError: (sambalist: to exclusive) kinit for [DC@Realm] failed (Cannot contact any KDC for requested realm)
- Winbind not able to start
- Winbind not able to start
- Winbind not able to start