similar to: Trust relationship fails after classicupgrade

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

Good morning! First of all thanks Rowland for the fast answer yesterday! I realized that samba-technical might have been the wrong mailing list and switched it to the normal samba users list (hopefully it worked, as it does get a bit confusing with spamgourmets sendto addresses!). Unfortunately the problem with samba_dnsupdate remains after the changes. I did changed the smb.conf, krb5.conf, and

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.

and.. change your nsswitch.conf >> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 to at least. >> hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4 Louis >-----Oorspronkelijk bericht----- >Van: rowlandpenny at googlemail.com >[mailto:samba-bounces at lists.samba.org] Namens Rowland Penny >Verzonden: zaterdag 11 april 2015 22:38

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. 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

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

I'm sorry it got confusing, changed the topic and I'll try to explain. I am using Jessie on the DC. Server13 is a linux file server and domain member, it is on squeeze. If possible, I do not want to upgrade it. The problem here is, that it does not seem to generate a DNS record when joining the domain and, after setting up the new smb.conf, the users aren't passed on from winbind to

Thank you for the answers Peter and Rowland and sorry to everybody for the spam...switched to another e-mail address and hope my messages will arrive only once from now on. As I wrote in my first mail, Kerberos does work. I can successfully request and list a ticket on the AC DC. kinit administrator at INTRANET.MAYWEG.NET Password for administrator at INTRANET.MAYWEG.NET: klist Ticket cache:

Hi Rowland, first and foremost thanks for the answer...on a saturday! Since I wrote I got it running! Did a complete purge of packages samba libnss-winbind libpam-winbind krb5-user krb5-config libpam-krb5 and reinstalled. Stopped smbd, nmbd and winbind and joined the domain. Started the services again and winbind could start as well. Thanks! Fyi, the smb.conf on AD (got a bit of a strange

Thank you Louis for that answer! Actually I did get kinit and samba_dnsupdate working, though I am unsure how. I tried some changes to krb5.conf in the [realms] and [domain_realm] sections, als well as setting dns_lookup_realm = false to true, but reverted it all back to the initial file: [libdefaults] default_realm = INTRANET.MAYWEG.NET dns_lookup_realm = false dns_lookup_kdc = true After a

Ok, I setup a new smb.conf and rebooted. Winbind doesn't seem to pass on the domain users anymore and the DNS Update during domain join still fails. For some reason, although I have all samba 3.5.6. packages installed on this debian squeeze samba -V or samba-tool are unknown commands. Maybe this is why the dns update fails, some missing tools or commands? wbinfo -u and wbinfo -g return domain

Hi guys, thanks again for the quick answers. First, the smb.conf on the linux fileserver. It is quite long, as I took the old file (working version from samba3 configuration) and only made adjustments, like adding the realm. /etc/samba/smb.conf: [global] ### Browsing/Identification ### workgroup = MAYWEG.NET realm = INTRANET.MAYWEG.NET netbios name = server13 smb ports = 139, 445

Good morning! First of all thanks Rowland for the fast answer yesterday! I realized that samba-technical might have been the wrong mailing list and switched it to the normal samba users list (hopefully it worked, as it does get a bit confusing with spamgourmets addresses!). Unfortunately the problem with samba_dnsupdate remains after the changes. I did changed the smb.conf, krb5.conf, and hosts

On 20 March 2015 at 17:00, Rowland Penny <rowlandpenny at googlemail.com> wrote: > On 20/03/15 15:47, Timo Altun wrote: > >> I'm sorry it got confusing, changed the topic and I'll try to explain. I >> am using Jessie on the DC. Server13 is a linux file server and domain >> member, it is on squeeze. If possible, I do not want to upgrade it. The >>

Try change your resolv.conf from : >nameserver 127.0.0.1 >domain intranet.mayweg.net to nameserver 192.168.11.250 search intranet.mayweg.net >The only thing I was unsure about, was which hostname to enter >for Kerberos >Server and Kerberos admin server when asked during the >installation of the >packages.. Try these defealt settings for kerberos.. You didnt have to

On 20/03/15 11:13, Timo Altun wrote: > Hi guys, > > thanks again for the quick answers. First, the smb.conf on the linux > fileserver. It is quite long, as I took the old file (working version from > samba3 configuration) and only made adjustments, like adding the realm. > > /etc/samba/smb.conf: > [global] > ### Browsing/Identification ### > > workgroup =

can you run these commands and tell us the output. ( copy past it. ) SETFQDN=`hostname -f` SETDNSDOMAIN=`hostname -d` SETHOSTNAME=`hostname -s` SETSERVERIP=`hostname -i` echo "==========Test DNS Records ===============================" echo "Testing : dns entries" if [ -z "`host -t SRV _ldap._tcp.${SETDNSDOMAIN}. | grep 'not found'`" ]; then echo

Timo Altun schrieb am 19.03.2015 10:30: > As I wrote in my first mail, Kerberos does work. I can successfully request > and list a ticket on the AC DC. OK, then next things, which come to my mind are: is the keytab, you set in named.conf.options readable for the user, under which bind is run. Then, is the /etc/bind/namedb writable for bind. And in the end, it might be a screwed up

Greetings, Timo Altun! > 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

Hi guys, we're testing the domain join of a Debian Wheezy machine to an Samba 4.17 AD with BIND9 backend (Debian Jessie). I can join the domain with "net ads join" alright, but "wbinfo -u" delivers nothing, cause winbind is not able to start. /etc/init.d/winbind status tells me it is not running. If I try winbindd -S -F I receive: initialize_winbindd_cache: clearing