Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
1
Installation and Upgrades / Re: DNS not resolving windows domain hosts
« on: July 30, 2014, 03:50:56 pm »
Shadow,
Windows machines will register themselves in DNS only after joining the domain, unless "Dynamic DNS Option" is Enabled in the Zentyal DHCP configuration menu tree.
If at any time you Enable or Disable "Dynamic DNS Option", it is a good idea to clear existing DNS records which have been automatically created because records of one owner cannot be updated by anybody else. If cleared, they should be re-created by the new owner at the first opportunity e.g when Workstation is turned on, when joining domain, upon ipconfig /release + ipconfig /renew, ipconfig /registerdns and as periodically requested by each Workstation.
Windows machines will register themselves in DNS only after joining the domain, unless "Dynamic DNS Option" is Enabled in the Zentyal DHCP configuration menu tree.
If at any time you Enable or Disable "Dynamic DNS Option", it is a good idea to clear existing DNS records which have been automatically created because records of one owner cannot be updated by anybody else. If cleared, they should be re-created by the new owner at the first opportunity e.g when Workstation is turned on, when joining domain, upon ipconfig /release + ipconfig /renew, ipconfig /registerdns and as periodically requested by each Workstation.
2
Installation and Upgrades / Re: Problems with Zentyal server as DNS server
« on: July 30, 2014, 03:29:17 pm »
MasseElch,
I presume that you want the Zentyal box to be the gateway for the 192.168.11.x network. If this is the case, make sure the DHCP configuration for network 192.168.11.x is properly configured to issue leases, INCLUDING :
- Default gateway : Zentyal;
- Primary nameserver : Local Zentyal DNS;
- NTP server : Local Zentyal NTP (make sure NTP is configured and ENABLED;
- WINS server : None;
- Dynamic DNS Options : take your pick - Disabled or Enabled - but DO NOT expect records created when Disabled to be maintained after you change to Enabled. Records are owned by the creator. If you decide to Enable or Disable, clear all workstation forward and reverse DNS records and let them be recreated by the new owner, so they'll behave nicely for ever after;
Having configured the above, which is the info each Workstation will receive when requesting a DHCP lease, bring your DHCP-configured Workstations on line then verify with "nslookup" whether DNS records have been created for each of them.
Please note that if Dynamic DNS Option is Disabled, DNS records will only be created after a Workstation joins the domain.
To be able to resolve EXTERNAL names from the 192.168.11.x network you will need to additionally configure your default gateway under menu "Network -> Gateways" and one or more DNS Forwarders under menu "DNS -> Forwarders".
I presume that you want the Zentyal box to be the gateway for the 192.168.11.x network. If this is the case, make sure the DHCP configuration for network 192.168.11.x is properly configured to issue leases, INCLUDING :
- Default gateway : Zentyal;
- Primary nameserver : Local Zentyal DNS;
- NTP server : Local Zentyal NTP (make sure NTP is configured and ENABLED;
- WINS server : None;
- Dynamic DNS Options : take your pick - Disabled or Enabled - but DO NOT expect records created when Disabled to be maintained after you change to Enabled. Records are owned by the creator. If you decide to Enable or Disable, clear all workstation forward and reverse DNS records and let them be recreated by the new owner, so they'll behave nicely for ever after;
Having configured the above, which is the info each Workstation will receive when requesting a DHCP lease, bring your DHCP-configured Workstations on line then verify with "nslookup" whether DNS records have been created for each of them.
Please note that if Dynamic DNS Option is Disabled, DNS records will only be created after a Workstation joins the domain.
To be able to resolve EXTERNAL names from the 192.168.11.x network you will need to additionally configure your default gateway under menu "Network -> Gateways" and one or more DNS Forwarders under menu "DNS -> Forwarders".
3
Installation and Upgrades / Re: seizing FSMO roles when the operations master crashes
« on: July 29, 2014, 06:49:42 pm »
interspatial,
This thread has been silent for a long time but only today did I came across it.
In the absence of the original roles holder, go to a surviving Additional Domain Controller and execute "sudo samba-tool fsmo seize --help".
This thread has been silent for a long time but only today did I came across it.
In the absence of the original roles holder, go to a surviving Additional Domain Controller and execute "sudo samba-tool fsmo seize --help".
4
Portuguese / Re: Ajuda- Dominio
« on: July 29, 2014, 06:16:29 pm »
Connect,
Duas opções iniciais, ambas pelo menu Users and Computers -> Manage:
1. altere o cadastro de seu próprio login, colocando-se no grupo "Domain Admins" e a partir daí você terá credenciais para incluir computadores no domínio;
2. altere a senha do usuário "Administrator", que já é membro do grupo "Domain Admins", e a partir daí inclua computadores no domínio usando as credenciais "Administrator" e a nova senha que você acabou de cadastrar. SOMENTE altere os campos "Password" e "Retype password", nada mais.
Lembre-se adicionalmente que para qualquer máquina ingressar no domínio seu relógio deve estar sincronizado com o controlador de domínio (DC) e sua configuração de rede deve estar corretamente apontando para o servidor DNS. Se você configurou seu servidor de DHCP para fornecer os endereços dos servidores DNS e NTP, o mais fácil para conseguir isso é configurando a máquina que vai ingressar no domínio para dinamicamente receber seu IP via DHCP (Painel de controle -> Rede -> etc).
Duas opções iniciais, ambas pelo menu Users and Computers -> Manage:
1. altere o cadastro de seu próprio login, colocando-se no grupo "Domain Admins" e a partir daí você terá credenciais para incluir computadores no domínio;
2. altere a senha do usuário "Administrator", que já é membro do grupo "Domain Admins", e a partir daí inclua computadores no domínio usando as credenciais "Administrator" e a nova senha que você acabou de cadastrar. SOMENTE altere os campos "Password" e "Retype password", nada mais.
Lembre-se adicionalmente que para qualquer máquina ingressar no domínio seu relógio deve estar sincronizado com o controlador de domínio (DC) e sua configuração de rede deve estar corretamente apontando para o servidor DNS. Se você configurou seu servidor de DHCP para fornecer os endereços dos servidores DNS e NTP, o mais fácil para conseguir isso é configurando a máquina que vai ingressar no domínio para dinamicamente receber seu IP via DHCP (Painel de controle -> Rede -> etc).
5
Installation and Upgrades / Re: I just installed Zentyal, latest version. What is the Administrator Console pas
« on: July 29, 2014, 05:04:10 pm »
For a new version 3.5 installation, if you are talking about the web-GUI or SSH access, the credentials are those of the user you created during the installation process.
Now if you are talking about LDAP - for instance joining computers to the domain - the "Administrator" user password can be re-entered from the menu Users and Computers -> Users -> Administrator. Make sure to ONLY enter data into the "Password" and "Retype password" fields and you´ll then end up with a known passord for the "Administrator" user.
To throw a cat amongst the pidgeons, please note that the option to "Change administrator password" under menu System -> General refers to that user created during installation and NOT the all-powerful "Administrator" user, member of the "Domain Admins" group.
I believe this conflict of nomenclature would be best removed in future Zentyal releases e.g. by calling the lesser user "Manager" and leaving "Administrator" to the LDAP/AD functions.
Now if you are talking about LDAP - for instance joining computers to the domain - the "Administrator" user password can be re-entered from the menu Users and Computers -> Users -> Administrator. Make sure to ONLY enter data into the "Password" and "Retype password" fields and you´ll then end up with a known passord for the "Administrator" user.
To throw a cat amongst the pidgeons, please note that the option to "Change administrator password" under menu System -> General refers to that user created during installation and NOT the all-powerful "Administrator" user, member of the "Domain Admins" group.
I believe this conflict of nomenclature would be best removed in future Zentyal releases e.g. by calling the lesser user "Manager" and leaving "Administrator" to the LDAP/AD functions.
6
Installation and Upgrades / Zentyal 3.5.1 Dynamic DNS no PTR Records
« on: July 29, 2014, 12:32:27 am »
Zentyal appears to handle three distinct types of automatic DNS registrations:
1. hosts added to the DNS Hostnames list will be nicely registered, both forward and reverse entries. This mechanism seems to work OK;
2. when DHCP "Dynamic DNS Option" is ENABLED, forward and reverse DNS records will be created each time DHCP issues a new lease. This mechanism also seems to work OK;
3. when DHCP "Dynamic DNS Option" IS NOT enabled, forward DNS records will be created each time a client so requests, e.g. when Windows workstations are powered up or upon ipconfig /release + ipconfig /renew or ipconfig /registerdns; however, PTR records ARE NOT created. This is the mechanism which IS NOT working for reverse records.
I have verified that PTR records can be made to work under these circumstances if the "update-policy" statement which controls updates from machines other than the local machine, in the declaration of reverse zones of file "/etc/bind/named.conf.local", is changed to update-policy {grant * wildcard * PTR TXT;};
Other more restrictive policies, such as specifying the wildcard *.0.168.192.in-addr.arpa in the tname field, also works with the "wildcard" matchtype. However I could not make work any policy utilizing matchtypes "subdomain" (as configured by Zentyal), "self", "tcp-self" or any others. It seems "tcp-self" would be the most appropriate matchtype for the job here.
Success or failure of a remote ipconfig/renew request can be monitored by "tail -f /var/log/syslog".
I was able to change the relevant line(s) of named.conf.local, by editing "/usr/share/zentyal/stubs/dns/named.conf.local.mas".
1. hosts added to the DNS Hostnames list will be nicely registered, both forward and reverse entries. This mechanism seems to work OK;
2. when DHCP "Dynamic DNS Option" is ENABLED, forward and reverse DNS records will be created each time DHCP issues a new lease. This mechanism also seems to work OK;
3. when DHCP "Dynamic DNS Option" IS NOT enabled, forward DNS records will be created each time a client so requests, e.g. when Windows workstations are powered up or upon ipconfig /release + ipconfig /renew or ipconfig /registerdns; however, PTR records ARE NOT created. This is the mechanism which IS NOT working for reverse records.
I have verified that PTR records can be made to work under these circumstances if the "update-policy" statement which controls updates from machines other than the local machine, in the declaration of reverse zones of file "/etc/bind/named.conf.local", is changed to update-policy {grant * wildcard * PTR TXT;};
Other more restrictive policies, such as specifying the wildcard *.0.168.192.in-addr.arpa in the tname field, also works with the "wildcard" matchtype. However I could not make work any policy utilizing matchtypes "subdomain" (as configured by Zentyal), "self", "tcp-self" or any others. It seems "tcp-self" would be the most appropriate matchtype for the job here.
Success or failure of a remote ipconfig/renew request can be monitored by "tail -f /var/log/syslog".
I was able to change the relevant line(s) of named.conf.local, by editing "/usr/share/zentyal/stubs/dns/named.conf.local.mas".
7
Installation and Upgrades / Re: Promote Zentyal BDC to PDC
« on: July 28, 2014, 11:44:59 pm »
Royceb,
From all I've read in the Samba4 traps and done with Zentyal since the early v 3.0 releases, there is no difference between a Domain Controller (DC) and Additional Domain Controllers (ADC), EXCEPT that the DC is the only machine that was originally involved in provisioning or establishing the domain and all ADCs have been estabished by replication from the DC.
Although Zentyal will forever show this distinction in the Domain -> Settings page of its web-GUI, I suppose - to answer your question - that the machine holding the PDC Emulator FSMO Role is the "pdc". If you wish to promote an ADC to DC, move all FSMO Roles accross to the new machine. This could be done with "samba-tool domain dcpromo ..." (this never worked for me) or with "samba-tool fsmo transfer ... | seize ..." (has worked for me).
From all I've read in the Samba4 traps and done with Zentyal since the early v 3.0 releases, there is no difference between a Domain Controller (DC) and Additional Domain Controllers (ADC), EXCEPT that the DC is the only machine that was originally involved in provisioning or establishing the domain and all ADCs have been estabished by replication from the DC.
Although Zentyal will forever show this distinction in the Domain -> Settings page of its web-GUI, I suppose - to answer your question - that the machine holding the PDC Emulator FSMO Role is the "pdc". If you wish to promote an ADC to DC, move all FSMO Roles accross to the new machine. This could be done with "samba-tool domain dcpromo ..." (this never worked for me) or with "samba-tool fsmo transfer ... | seize ..." (has worked for me).
8
Installation and Upgrades / Re: DHCP STATIC LEASE FOR DHCP CLIENT
« on: June 27, 2014, 09:20:49 pm »
Lim,
You seem to be doing all that is needed. However IP addresses assigned to objects CANNOT fall within any existing DHCP ranges. Let's say in subnet 192.168.10.0/24 you have defined a DHCP range "main" spanning from 192.168.10.101 to 192.168.10.200. In this case you may use object IPs in the range 192.168.10.1 to 192.168.10.100 AND in the range 192.168.10.201 to 192.168.10.254 because none of these IPs would conflict with range "main". If you satisfy this condition then the IP of a given object will be served to the interface which has the associated MAC address. Naturally, your PC interface should remain configured for dhcp but will now receive the desired IP.
You seem to be doing all that is needed. However IP addresses assigned to objects CANNOT fall within any existing DHCP ranges. Let's say in subnet 192.168.10.0/24 you have defined a DHCP range "main" spanning from 192.168.10.101 to 192.168.10.200. In this case you may use object IPs in the range 192.168.10.1 to 192.168.10.100 AND in the range 192.168.10.201 to 192.168.10.254 because none of these IPs would conflict with range "main". If you satisfy this condition then the IP of a given object will be served to the interface which has the associated MAC address. Naturally, your PC interface should remain configured for dhcp but will now receive the desired IP.
9
Installation and Upgrades / Re: Removing dead domain controllers
« on: August 20, 2013, 06:57:01 pm »
You need to look at the DNS records for your domain. If you have an XP machine with SP1 or later, download and install "Windows Server 2003 Adminpak". If you have Windows 7, download and install "RSAT". It is possible to remove the mentioned records with other free tools such as "Ldapadmin", but it not as straightforward to confidently find the required uuid of the stale DC as it is with RSAT and its predecessor 2003 Adminpak.
10
Installation and Upgrades / Re: Switching server roles betwee Domain Controller and Additional Domain Controller
« on: August 20, 2013, 03:46:24 pm »
From what I have read, the Samba4 Team discourages the use of the PDC/BDC terminology and concepts. I understand that all DCs are identical in nature and can do the same things. In general terms, the first DC installed in a particular domain is "provisioned" with a brand new LDAP database, DNS and the rest of it and, for this reason, is referred to as "The Domain Controller". All other DCs joined thereafter are referred to as "Additional Domain Controllers", although they can be in essence exact replicas of the original DC.
After one or more DCs co-exist in a domain, it seems to me that there are no diferences between "The Domain Controller" and all "Additional Domain Controllers", except that "The Domain Controller" will retain all FSMO roles (these, by definition, can only be held by one DC at a time) until one or more roles are explicitly transferred to one or more other "Additional Domain Controllers".
So, it not difficult to see that all DCs are made alike and the distinction between "Domain Controller" and "Additional Domain Controller" may become blurred after the initial "provisioning" and "joining" process, through normal life cycle management operations.
I have found that Zentyal adheres to the apparent Samba4 naming convention, permanently calling "Domain Controller" the first DC which "provisioned" the domain infrastructure, regardless of whether any or all FSMO roles are subsequently atributed to an "Additional Domain Controller".
Accordingly, I suggest that the term "Domain Controller" should perhaps be used indiscriminately for all DCs, regardless of whether they were the first, second or Nth to participate in their domain. Likewise, additional domain controller should not have any special meaning except to identify "Domain Controllers" which join an existing domain.
From the Zentyal "File Sharing" GUI point of view, perhaps the screen should be split into two areas:
1. one area for all DCs, in essence what is now the configuration of a "Domain controller";
2. a bit lower down, an area for additional parameters to allow joining of "Additional domain controllers" e.g. "Existing Domain controller FQDN:", "Domain DNS server IP:", "Administrator account:", "Administrator password:".
After one or more DCs co-exist in a domain, it seems to me that there are no diferences between "The Domain Controller" and all "Additional Domain Controllers", except that "The Domain Controller" will retain all FSMO roles (these, by definition, can only be held by one DC at a time) until one or more roles are explicitly transferred to one or more other "Additional Domain Controllers".
So, it not difficult to see that all DCs are made alike and the distinction between "Domain Controller" and "Additional Domain Controller" may become blurred after the initial "provisioning" and "joining" process, through normal life cycle management operations.
I have found that Zentyal adheres to the apparent Samba4 naming convention, permanently calling "Domain Controller" the first DC which "provisioned" the domain infrastructure, regardless of whether any or all FSMO roles are subsequently atributed to an "Additional Domain Controller".
Accordingly, I suggest that the term "Domain Controller" should perhaps be used indiscriminately for all DCs, regardless of whether they were the first, second or Nth to participate in their domain. Likewise, additional domain controller should not have any special meaning except to identify "Domain Controllers" which join an existing domain.
From the Zentyal "File Sharing" GUI point of view, perhaps the screen should be split into two areas:
1. one area for all DCs, in essence what is now the configuration of a "Domain controller";
2. a bit lower down, an area for additional parameters to allow joining of "Additional domain controllers" e.g. "Existing Domain controller FQDN:", "Domain DNS server IP:", "Administrator account:", "Administrator password:".
11
Installation and Upgrades / Re: Removing dead domain controllers
« on: August 20, 2013, 03:03:41 pm »
When running "samba-tool domain join" at a command line the messages indicate that it cleans up a lot of dead pointers before creating new ones. I have found that by identifying the uuid of the dead DC through examination of an Alias(CNAME) record in the DNS Forward Zone "_msdcs.<YOUR-DOMAIN>", then it suffices to remove the following two records from this zone, to successfully join another DC of the same name:
1. the uuid Alias itself;
2. the "_ldap._tcp.<uuid>.domains" record;
Note that if you are using the RSAT DNS Manager, the second record will be found under "domains" in the tree browser of the "_msdcs.<YOUR.DOMAIN>" Forward Zone. The tell-tale uuid will stick out like a sore thumb.
You may have subsidiary Zentyal issues but, generally, joining of a DC of the same name will occur after removal of these two mentioned DNS records.
1. the uuid Alias itself;
2. the "_ldap._tcp.<uuid>.domains" record;
Note that if you are using the RSAT DNS Manager, the second record will be found under "domains" in the tree browser of the "_msdcs.<YOUR.DOMAIN>" Forward Zone. The tell-tale uuid will stick out like a sore thumb.
You may have subsidiary Zentyal issues but, generally, joining of a DC of the same name will occur after removal of these two mentioned DNS records.
12
Installation and Upgrades / Re: Switching server roles betwee Domain Controller and Additional Domain Controller
« on: August 20, 2013, 02:26:29 pm »
11 days on and in the absence of any comments from Zentyal I might add that notwithstanding my DC still identifying itself as an "Additional domain controller" it certainly is working as the "Domain cntroller". The same can be said about my additional domain controller, even though it identifies itself as the "Domain controller".
However, it would be nice to know how to clean up this case of switched identities seeing it was generated through simulation of a real-life situation.
However, it would be nice to know how to clean up this case of switched identities seeing it was generated through simulation of a real-life situation.
13
Installation and Upgrades / Re: DHCP option tag 60
« on: August 16, 2013, 09:16:04 pm »
Search for "dhcpd.conf syntax" to see shed some light on how to edit this file. It might be relevant to your needs to consider that a PXE server is commonly identified by the "next-server" parameter of dhcpd.conf. Zentyal appears to support the configuration of a next server under DHCP -> Advanced options -> Thin clients. You might want to follow this up.
14
Installation and Upgrades / Switching server roles betwee Domain Controller and Additional Domain Controller
« on: August 09, 2013, 09:59:04 pm »
I have two identical Zentyal 3.0.23 servers, dc02 configured as a DC and dc01 as an Additional DC.
Replication between them works fine and most everything is working OK. I wanted to switch their server roles, making dc01 assume the DC role and dc02 the Additional DC. To this end, I transferred the 5 FSMO roles from dc02 to dc01 and then manually edited the fSMORoleOwner of DC=DomainDnsZones, CN=Infrastructure and of DC=ForestDnsZones, CN= Infrastructure, changing "DC02" to "DC01" at both places. It appears that dc01 is now indeed behaving as the DC and dc02 as the Additional DC, as I intended. However, in the Zentyal WebGUI, "File Sharing" has not changed and continues to show dc02 as the DC and dc01 as the Additional DC. Why ?
Replication between them works fine and most everything is working OK. I wanted to switch their server roles, making dc01 assume the DC role and dc02 the Additional DC. To this end, I transferred the 5 FSMO roles from dc02 to dc01 and then manually edited the fSMORoleOwner of DC=DomainDnsZones, CN=Infrastructure and of DC=ForestDnsZones, CN= Infrastructure, changing "DC02" to "DC01" at both places. It appears that dc01 is now indeed behaving as the DC and dc02 as the Additional DC, as I intended. However, in the Zentyal WebGUI, "File Sharing" has not changed and continues to show dc02 as the DC and dc01 as the Additional DC. Why ?
15
Installation and Upgrades / NexentaStor unable to join Zentyal 3 domain
« on: April 04, 2013, 09:07:55 pm »
What procedure should be followed to make NexentaStor 3.1.3.5 CE join a Samba4 domain controlled by a Zentyal 3.0.16 Domain Controller ?
I have unsuccessfully tried running Zentyal at domain levels 2003, 2008 and 2008 R2,where it now sits.
When I set lmauth_level=4 at the Nexenta side, I get the following errors after running "smbadm join -u Administrator mydomain.loc":
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 972153 daemon.error] smbns_ksetpwd: KPASSWD protocol exchange failed (Message stream modified)
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 702911 daemon.notice] Failed to set machine password.
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 871254 daemon.error] smbd: failed joining mydomain.loc (UNSUCCESSFUL)
If I set lmauth_level=2, the error then becomes:
Apr 4 15:43:32 nexenta04 smbd[10056]: [ID 807464 daemon.error] ndr_rpc_bind: smbrdr_ctx_new(S=dc02, D=mydomain.loc, U=Administrator), err=48
Apr 4 15:43:32 nexenta04 last message repeated 3 times
Apr 4 15:43:32 nexenta04 smbd[10056]: [ID 871254 daemon.error] smbd: failed joining mydomain.loc (LOGON_FAILURE)
What can be inferred from the above two sets of messages ? Is there a problem with kpasswd or kerberos ? What is a sensible way to debug this ?
This problem persists since Zentyal 3.0.3.
Note 1: The same NexentaStor installation joins a Windows Server 2003 domain without effort.
Note 2: The prior Solaris 11 11/11 joins the domain controlled by Zentyal also effortlessly BUT the more recent Solaris 11.1ga does not.
Help will be appreciated.
I have unsuccessfully tried running Zentyal at domain levels 2003, 2008 and 2008 R2,where it now sits.
When I set lmauth_level=4 at the Nexenta side, I get the following errors after running "smbadm join -u Administrator mydomain.loc":
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 972153 daemon.error] smbns_ksetpwd: KPASSWD protocol exchange failed (Message stream modified)
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 702911 daemon.notice] Failed to set machine password.
Apr 4 09:58:37 nexenta04 smbd[10056]: [ID 871254 daemon.error] smbd: failed joining mydomain.loc (UNSUCCESSFUL)
If I set lmauth_level=2, the error then becomes:
Apr 4 15:43:32 nexenta04 smbd[10056]: [ID 807464 daemon.error] ndr_rpc_bind: smbrdr_ctx_new(S=dc02, D=mydomain.loc, U=Administrator), err=48
Apr 4 15:43:32 nexenta04 last message repeated 3 times
Apr 4 15:43:32 nexenta04 smbd[10056]: [ID 871254 daemon.error] smbd: failed joining mydomain.loc (LOGON_FAILURE)
What can be inferred from the above two sets of messages ? Is there a problem with kpasswd or kerberos ? What is a sensible way to debug this ?
This problem persists since Zentyal 3.0.3.
Note 1: The same NexentaStor installation joins a Windows Server 2003 domain without effort.
Note 2: The prior Solaris 11 11/11 joins the domain controlled by Zentyal also effortlessly BUT the more recent Solaris 11.1ga does not.
Help will be appreciated.
Pages: [1] 2