powered by Jive Software

Tutorial - Single Sign-On (SSO) - Server SAMBA on FreeBSD and Openfire on Ubuntu and Spark on Windows


  • configurando o SAMBA 48, COM BIND 911 (DLZ) no FreeBSD para realizar *
  • Single Sign-on (SSO) com o Serviço de chat xmpp/jabber Openfire no *
  • Ubuntu e clientes Spark 2.7.7 em hosts Windows. *


  •                        FEITO, ESCRITO E TESTADO POR RICARDO XERFAN                         *
    
  •                               GRAÇAS A DEUS, TUDO CERTO!!!                                 *
    
  •                               DATA: 02/09/2018 - MACAPÁ-AP                                 *
    

=================================
OBSERVAÇÃO MUITO IMPORTANTE PARA SSO

** ESTA OBSERVAÇÃO FOI INCLUÍDA A ESTE TUTORIAL, EM 05/09/2018, PELO SEGUINTE MOTIVO: EM TESTES REALIZADOS AO LADO DO COLEGA DHIEMESON NASCIMENTO, EM BANCO DE DADOS, PARA HOMOLOGAÇÃO, COM UM MAIOR VOLUME DE DADOS PARA TESTES, VERIFICOU-SE QUE APRESENTOU UM ERRO AO TENTAR FAZER SINGLE SIGN-ON (SSO) EM HOSTS SPARK/WINDOWS COM USUÁRIOS PERTENCENTES A DETERMINADOS GRUPOS ADMINISTRATIVOS DO DOMÍNIO (ESPECIFICAMENTE NESSE ASPECTO). E PELO FATO DE TER SIDO MEIO DIFÍCIL DE DESCOBRIR, SEGUE MAIORES INFORMAÇÕES:

	NÃO ADICIONE OS SEGUINTES GRUPOS AS SEUS USUÁRIOS:

			Domain Admins
			Group Policy Creator Owners
			Schema Admins

	*** CASO ADICIONE ALGUM DESSES GRUPOS (QUALQUER UM, INDEPENDENTE SE FOR SOMENTE UM, DOIS OU TODOS ESTES) AO USUÁRIO OU GRUPO AO QUAL ELE PERTENÇA, VAI APRESENTAR ERRO NA HORA DE REALIZAR O SSO NO CLIENTE SPARK COM WINDOWS, POIS ELE NÃO VAI CONSEGUIR DETERMINAR O NOME DE USUÁRIO E O FQDN DO MESMO, APRESENTANDO POR CONSEQUÊNCIA A MENSAGEM (UNABLE TO DETERMINE).

===============================================================================

===============================================================================
PREPARAÇÃO DO SERVIDOR FreeBSD
COM SAMBA48 E BIND 911

=================================
INSTALAÇÃO DO SAMBA

*OBS.1: Para este ambiente, foi utilizado a instalação do SAMBA via Ports no FreeBSD. Para mais detalhes sobre esse tipo de instalação, acesse o link abaixo:

https://www.freebsd.org/ports/

https://www.youtube.com/watch?v=7xMBH-WwY3Y

Passo 1:

Atualizar a coleção de ports do FreeBSD:

	# portsnap fetch update

PASSO EXTRA 1:

OBS.EXTRA.1-1: Como o Kerberos é sensível ao tempo, recomenda-se que seja instalado o pacote NTP. Essa instalação pode ser feita via PKG:
	
	Atualizar o pkg:
	
		# pkg update
		
	Instalar o pacote NTP:
	
		# pkg install ntp
	
	Iniciar o daemon:
	
		# /etc/rc.d/ntpd start

Passo 2:

Entrar no diretório ports do SAMBA e instalar o mesmo:

	# cd /usr/ports/net/samba48/

	# make install clean

*OBS.2: Na caixa de diálogo que aparecerá, escolha o DNS BIND, NA VERSÃO COMPATÍVEL COM O SAMBA QUE FOI ESCOLHIDO:
		
		===========================================
		BIND Version |  Supported in Samba Version
		===========================================
		BIND 9.11	Samba 4.5.2 and later
		BIND 9.10	Samba 4.2 and later
		BIND 9.9	Samba 4.0 and later
		BIND 9.8	Samba 4.0 and later

	Para mais informações de como configurar o BIND e qual a versão suportada no SAMBA escolhido, acesse:

		https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End#Configuring_the_BIND9_DLZ_Module

*OBS.3: Na caixa de diálogo que aparecerá sobre o BIND, escolha a opção GSSAPI Heimdal.

=================================
ARQUIVOS DE CONFIGURAÇÃO DO SERVIDOR

Passo 3:

Configurar os arquivos "/etc/hosts", "/etc/resolv.conf" e "/etc/rc.conf" de acordo com o seu ambiente:

	# ee /etc/hosts
	
		::1                     localhost localhost.my.domain
		127.0.0.1               localhost localhost.my.domain
		192.168.2.60            svr02 svr02.freedom.local

			*OBS.4: Aqui é bom que já se coloque o FQDN do servidor atrelado ao endereço IP do mesmo, pois na hora da configuração do SAMBA --interactive ele já pega as configurações do REALM e do Domain automaticamente.
		
	# ee /etc/resolv.conf

		#search freedom.local
		domain freedom.local
		#nameserver 192.168.2.60
		nameserver 127.0.0.1

		
	# ee /etc/rc.conf
	
		hostname="svr02.freedom.local"
		keymap="br.kbd"
		ifconfig_em0="inet 192.168.2.60 netmask 255.255.255.0"
		defaultrouter="192.168.2.254"
		sshd_enable="YES"
		#named_enable="YES"
		#samba_server_enable="YES"
		ntpd_enable="YES"
		# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
		dumpdev="AUTO"
		
			*OBS.4: Não há a necessidade de que seja colocado o FQDN na opção "hostname", basta apenas o nome do servidor.
			*OBS.5: NÃO HABILITE AINDA as variáveis (named_enable="YES") e (samba_server_enable="YES").

Passo 4:

É bom que seja reiniciado o servidor:

	# shutdown -r now

=================================
PROVISIONAMENTO DO SAMBA

Passo 5:

Provisionamento (ou promoção do Servidor a nível de Controlador de Domínio) do SAMBA em modo interativo:

	# samba-tool domain provision --use-rfc2307 --interactive
	
		*PARÂMETROS:
		
			--use-rfc2307
			
				Mapeamento de entidades relacionadas ao TCP/IP e ao sistema UNIX no X.500. Entradas para que possam ser resolvidas com o LDAP. Para mais informações, acesse o link abaixo:
					
					https://tools.ietf.org/html/rfc2307


			--interactive
			
				Permite que vc escolha as opções, passo-a-passo, durante provisionamento.
	
		
		*OBS.6: No momento do provisionamento, na hora da escolha do DNS backend, digite "BIND9_DLZ" (sem aspas).
		
			DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: BIND9_DLZ
		
		*OBS.7: No momento do provisionamento, na hora da escolha do IP do DNS Forwarder, digite o IP do próprio servidor (depois de tudo configurado pode ser alterado isso, mas no momento deve ser apontado para o próprio servidor):
		
			DNS forwarder IP address (write 'none' to disable forwarding) [192.168.2.60]:
			
		*OBS.8: AINDA NÃO START O SAMBA.

=================================
CONFIGURAÇÃO DO BIND

*OBS.8: As configurações descritas aqui devem ser feitas com bastante atenção, pois o processo de SSO que será feito depois, depende de um DNS bem configurado para que funcione, justamente porque o Kerberos necessita disso. Para mais informações sobre a configuração do BIND, acesse:

https://wiki.samba.org/index.php/Setting_up_a_BIND_DNS_Server

https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End

*OBS.9: Para os passos a seguir, é necessário que se saiba a localização correta dos arquivos de configuração do DNS no SAMBA e do DNS no BIND, ambos com o nome “named.conf” para isso execute o comando a seguir:

	*PARA O SAMBA:
	 
			# smbd -b
	 
				Procure então pela variável "BINDDNS_DIR" (sem aspas):

					BINDDNS_DIR: /var/db/samba4/bind-dns
		
				O comando pode ser feito desta forma também:
	
					# smbd -b |grep BINDDNS_DIR:
		
						BINDDNS_DIR: /var/db/samba4/bind-dns
	
				Ou simplesmente procure o arquivo "named.conf" com o "find" e abra o que está no diretório do SAMBA:
	
					# find / -iname named.conf
		
						/var/db/samba4/bind-dns/named.conf

	*PARA O BIND:
			
			Localize o daemon do BIND:
			
				# which named
				
					/usr/local/sbin/named
				
			Execute então o comando no caminho encontrado:
			
				# /usr/local/sbin/named -V
				
			Procure então pela variável "--sysconfdir=" (sem aspas)
			
				'--sysconfdir=/usr/local/etc/namedb'
								
			Ou simplesmente procure o arquivo "named.conf" com o "find" e abra o que está no diretório do BIND (namedb):
	
				# find / -iname named.conf
		
					/usr/local/etc/namedb/named.conf

IMPORTANTE: Verifique também se foi compilado com suporte a GSSAPI e atualizações de DNS dinâmicas seguras usando o Kerberos, para isso procure a variável “–with-gssapi=” (’–with-gssapi=/usr/local’ ou ‘–with-gssapi=yes’ ou similar), caso apareça a opção “’–without-gssapi’”, significa que o BIND não foi compilado com suporte a GSSAPI, neste caso vc terá que desinstalar e instalar novamente o BIND, escolhendo a opção que dê suporte ao GSSAPI Heimdal. Verifique também se foi compilado com suporte a zonas dinamicamente carregáveis (DLZ), para isso procure a variável “–with-dlopen=” (’–with-dlopen=yes’), caso apareça “’–without-dlopen’” desinstale e instale novamente o BIND com suporte a essa opção.

*OBS.10: Certifique-se de que o serviço do BIND não esteja rodando, caso esteja levantado, pare o mesmo:

# service named status
# service named stop

Passo 6:

Configuração do arquivo "named.conf" do BIND:

	*OBS.11: Essa configuração depende do caminho certo de localização do arquivo "named.conf" do SAMBA (por isso que foi falado sobre como localizar os arquivos acima) e da inserção da cláusula no local correto dentro do arquivo, caso contrário vai dar erro.
	
		Edite o arquivo "named.conf":
		
			# ee /usr/local/etc/namedb/named.conf
		
		Insira a seguinte cláusula no arquivo:
		
			include "/var/db/samba4/bind-dns/named.conf";
			
				*OBS.12: Esta cláusula deve ser inserida ou antes do início, ou depois (logo abaixo) da seguinte seção (NUNCA INSIRA DENTRO):
				
					options {
						[...]
					};
	
		Insira os seguintes parâmetros dentro seção "options":
				
			options {
				[...]
				tkey-gssapi-keytab "/var/db/samba4/bind-dns/dns.keytab";
				listen-on port 53 { any; };
				allow-query { any; };
				recursion yes;
				[...]
			};

Passo 7:

Configuração do arquivo "named.conf" do SAMBA:

		Edite o arquivo "named.conf":
		
			# ee /var/db/samba4/bind-dns/named.conf
			
		Descomente, na seção "dlz "AD DNS Zone"", a linha correspondente a versão do BIND que foi instalado:
		
			dlz "AD DNS Zone" {
				# For BIND 9.8.x
				# database "dlopen /usr/local/lib/shared-modules/bind9/dlz_bind9.so";

				# For BIND 9.9.x
				# database "dlopen /usr/local/lib/shared-modules/bind9/dlz_bind9_9.so";

				# For BIND 9.10.x
				# database "dlopen /usr/local/lib/shared-modules/bind9/dlz_bind9_10.so";

				# For BIND 9.11.x
				database "dlopen /usr/local/lib/shared-modules/bind9/dlz_bind9_11.so";
			};

PASSO EXTRA 2

OBS.EXTRA.2-1: Se o usuário que for executar o BIND no SAMBA for diferente do default na hora da instalação, altere as permissões, dono e grupo do arquivo "dns.keytab" de acordo com o usuário e grupo escolhido:

	# chmod 755 /var/db/samba4/bind-dns/dns.keytab
	
	# chown root:bind /var/db/samba4/bind-dns/dns.keytab

Passo 8:

Cheque se as configurações do BIND estão ok:

	# named-checkconf

*OBS.12: A saída padrão desse comando é não apresentar nenhuma mensagem, caso apresente alguma mensagem de erro, com base na mensagem apresentada, verifique as configurações dos arquivos "named.conf" e depois refaça o teste com esse mesmo comando.

Passo 10:

Localize o diretório do arquivo de configuração do SAMBA:

			# smbd -b
	 
				Procure então pela variável "CONFIGFILE" (sem aspas):

					CONFIGFILE: /usr/local/etc/smb4.conf
		
				O comando pode ser feito desta forma também:
	
					# smbd -b |grep CONFIGFILE:
		
						CONFIGFILE: /usr/local/etc/smb4.conf
	
				Ou simplesmente procure o arquivo "smb4.conf" com o "find":
	
					# find / -iname smb4.conf
		
						/usr/local/etc/smb4.conf
						
Edite o arquivo "smb4.conf":

	ee /usr/local/etc/smb4.conf

Desative o DNS interno do SAMBA, removendo a opção "dns" (sem aspas) do parâmetro "server services" (sem aspas) dentro da seção "[global]" (sem aspas) no arquivo "smb4.conf":

	server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
	 
Caso não tenha o parâmetro "server services" no arquivo "smb4.conf", apenas o inclua juntamente com a opção "-dns" dentro da seção "[global]" (sem aspas):

	server services = -dns

Passo 11:

Descomente ou insira as variáveis (named_enable="YES") e (samba_server_enable="YES") no arquivo "rc.conf" do servidor:

		# ee /etc/rc.conf
	
		hostname="svr02.freedom.local"
		keymap="br.kbd"
		ifconfig_em0="inet 192.168.2.60 netmask 255.255.255.0"
		defaultrouter="192.168.2.254"
		sshd_enable="YES"
		named_enable="YES"
		samba_server_enable="YES"
		ntpd_enable="YES"
		# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
		dumpdev="AUTO"

Passo 12:

Gere a key rndc:

	# rndc-confgen -a -r /dev/urandom
		
		A saída desse comando deve ser parecida com essa:
		
			wrote key file "/usr/local/etc/namedb/rndc.key"
		
					IMPORTANTE: O RNDC controla a operação de um servidor de nomes. O rndc usa a conexão tcp para se comunicar com o servidor de ligação para enviar comandos autenticados com assinaturas digitais. Mais informações, acesse:
				
							https://tecadmin.net/configure-rndc-for-bind9/
					
							https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.rndc-confgen.html
							
							https://linuxconfig.org/configure-rndc-key-for-bind-dns-server-on-centos-7

Passo 13:

Inicie o serviço do BIND:

	# service named start
	
Inicie o serviço do SAMBA:

	# service samba_server start

Passo 14:

Atualização dinâmica da base do DNS do SAMBA no BIND:

	# samba_dnsupdate --verbose --all-names

=================================
DEMAIS VERIFICAÇÕES DO SAMBA

Passo 15:

Teste inicial do SAMBA. Listar os compartilhamentos/ mapeamentos:

	# smbclient -L localhost -U%
	
		A saída desse comando deve ser parecida com essa:
		
		        Sharename       Type      Comment
				---------       ----      -------
				netlogon        Disk
				sysvol          Disk
				IPC$            IPC       IPC Service (Samba 4.8.0)
		Reconnecting with SMB1 for workgroup listing.

				Server               Comment
				---------            -------

				Workgroup            Master
				---------            -------

Testar a conexão com o diretório "netlogon" e listar o conteúdo do mesmo:

	# smbclient //localhost/netlogon -UAdministrator -c 'ls'
	
		A saída desse comando deve ser parecida com essa:
		
				Enter FREEDOM\Administrator's password:
				  .                                   D        0  Thu Aug 30 02:14:06 2018
				  ..                                  D        0  Thu Aug 30 02:14:15 2018

								28433628 blocks of size 1024. 23406300 blocks available
								
Confirmar o nível do Domínio:

	# samba-tool domain level show
		
		A saída desse comando deve ser parecida com essa:
		
				Domain and forest function level for domain 'DC=freedom,DC=local'

				Forest function level: (Windows) 2008 R2
				Domain function level: (Windows) 2008 R2
				Lowest function level of a DC: (Windows) 2008 R2
			
Testar se foi criado o registro de serviço (SRV) do LDAP:

	# host -t SRV _ldap._tcp.freedom.local.
		
		A saída desse comando deve ser parecida com essa:
		
			_ldap._tcp.freedom.local has SRV record 0 100 389 svr02.freedom.local.


*OBS.13: CASO APRESENTE ERRO NO COMANDO ANTERIOR, realize o procedimento descrito no "PASSO EXTRA 3" abaixo e refaça o teste anterior:

PASSO EXTRA 3

OBS.EXTRA.3-1: CASO APRESENTE ALGUM ERRO, COMO DE O DNS NÃO LOCALIZAR OS REGISTROS DENTRO DA BASE, REALIZE ESSE PASSO.

	# samba_upgradedns --dns-backend=BIND9_DLZ
		
		A saída desse comando deve ser parecida com essa:
		
			Reading domain information
			DNS accounts already exist
			No zone file /var/db/samba4/bind-dns/dns/FREEDOM.LOCAL.zone
			DNS records will be automatically created
			DNS partitions already exist
			dns-svr02 account already exists
			See /var/db/samba4/bind-dns/named.conf for an example configuration include file for BIND
			and /var/db/samba4/bind-dns/named.txt for further documentation required for secure DNS updates
			Finished upgrading DNS		

Testar se foi criado o registro de serviço (SRV) do Kerberos:

	# host -t SRV _kerberos._udp.freedom.local.
	
		A saída desse comando deve ser parecida com essa:
		
			_kerberos._udp.freedom.local has SRV record 0 100 88 svr02.freedom.local.

Testar se foi criado o registro de host (A) do servidor local:

	# host -t A svr02.freedom.local.
	
		A saída desse comando deve ser parecida com essa:
		
			svr02.freedom.local has address 192.168.2.60
			
Saber se o Kerberos está funcionando. Para isso gere um ticket para o Administrador:

	# kinit administrator@FREEDOM.LOCAL

Caso não apresente erro no comando anterior, verifique se foi criado o ticket:

	# klist -v
	
		A saída desse comando deve ser parecida com essa:
		
			Credentials cache: FILE:/tmp/krb5cc_0
					Principal: administrator@FREEDOM.LOCAL
				Cache version: 4

			Server: krbtgt/FREEDOM.LOCAL@FREEDOM.LOCAL
			Client: administrator@FREEDOM.LOCAL
			Ticket etype: aes256-cts-hmac-sha1-96, kvno 1
			Ticket length: 1110
			Auth time:  Sep  2 16:31:45 2018
			End time:   Sep  3 02:31:43 2018
			Ticket flags: pre-authent, initial, forwardable
			Addresses: addressless

ATENÇÃO: ATÉ AQUI O SEU SERVIDOR SAMBA JÁ DEVE SER CAPAZ DE FAZER QUALQUER TAREFA RELACIONADA AO CONTEXTO DE CONTROLADOR DE DOMÍNIO, NO ENTANTO, É NECESSÁRIO QUE SE CRIE A ZONA INVERSA E SE ADICIONE MAIS ALGUNS REGISTROS DOS TIPOS “A” e “PTR” AO DNS BIND PARA QUE FUNCIONE CORRETAMENTE A CONFIGURAÇÃO DE SINGLE SIGN-ON (SSO) QUE SERÁ IMPLEMENTADA.

=================================
CRIAR ZONA REVERSA NO DNS

Passo 16:

Listar as zonas que já estão criadas no servidor DNS:

	# samba-tool dns zonelist 127.0.0.1 -U Administrator
	
		A saída desse comando deve ser parecida com essa:
	
				Password for [FREEDOM\Administrator]:
				  2 zone(s) found

				  pszZoneName                 : freedom.local
				  Flags                       : DNS_RPC_ZONE_DSINTEGRATED DNS_RPC_ZONE_UPDATE_SECURE
				  ZoneType                    : DNS_ZONE_TYPE_PRIMARY
				  Version                     : 50
				  dwDpFlags                   : DNS_DP_AUTOCREATED DNS_DP_DOMAIN_DEFAULT DNS_DP_ENLISTED
				  pszDpFqdn                   : DomainDnsZones.freedom.local

				  pszZoneName                 : _msdcs.freedom.local
				  Flags                       : DNS_RPC_ZONE_DSINTEGRATED DNS_RPC_ZONE_UPDATE_SECURE
				  ZoneType                    : DNS_ZONE_TYPE_PRIMARY
				  Version                     : 50
				  dwDpFlags                   : DNS_DP_AUTOCREATED DNS_DP_FOREST_DEFAULT DNS_DP_ENLISTED
				  pszDpFqdn                   : ForestDnsZones.freedom.local

Criar a Zona Reversa no seridor DNS:

	# samba-tool dns zonecreate 127.0.0.1 2.168.192.in-addr.arpa -U Administrator
	
		A saída desse comando deve ser parecida com essa:
		
				Password for [FREEDOM\Administrator]:
				Zone 2.168.192.in-addr.arpa created successfully

Listar, novamente, as zonas que já estão criadas no servidor DNS:

	# samba-tool dns zonelist 127.0.0.1 -U Administrator
	
		A saída desse comando deve ser parecida com essa:
		
				Password for [FREEDOM\Administrator]:
				  3 zone(s) found

				  pszZoneName                 : freedom.local
				  Flags                       : DNS_RPC_ZONE_DSINTEGRATED DNS_RPC_ZONE_UPDATE_SECURE
				  ZoneType                    : DNS_ZONE_TYPE_PRIMARY
				  Version                     : 50
				  dwDpFlags                   : DNS_DP_AUTOCREATED DNS_DP_DOMAIN_DEFAULT DNS_DP_ENLISTED
				  pszDpFqdn                   : DomainDnsZones.freedom.local

				  pszZoneName                 : 2.168.192.in-addr.arpa
				  Flags                       : DNS_RPC_ZONE_DSINTEGRATED DNS_RPC_ZONE_UPDATE_SECURE
				  ZoneType                    : DNS_ZONE_TYPE_PRIMARY
				  Version                     : 50
				  dwDpFlags                   : DNS_DP_AUTOCREATED DNS_DP_DOMAIN_DEFAULT DNS_DP_ENLISTED
				  pszDpFqdn                   : DomainDnsZones.freedom.local

				  pszZoneName                 : _msdcs.freedom.local
				  Flags                       : DNS_RPC_ZONE_DSINTEGRATED DNS_RPC_ZONE_UPDATE_SECURE
				  ZoneType                    : DNS_ZONE_TYPE_PRIMARY
				  Version                     : 50
				  dwDpFlags                   : DNS_DP_AUTOCREATED DNS_DP_FOREST_DEFAULT DNS_DP_ENLISTED
				  pszDpFqdn                   : ForestDnsZones.freedom.local

=================================
ADICIONAR REGISTROS DOS TIPOS “A” e “PTR” NO DNS

Passo 17:

Criar o registro do tipo "A" na zona direta do DNS do SAMBA, para o servidor que ficará hospedado o serviço do Chat xmpp/jabber Openfire:

	# samba-tool dns add 127.0.0.1 freedom.local svrchat.freedom.local A 192.168.2.70 -U Administrator
	
		A saída desse comando deve ser parecida com essa:
				
				Password for [FREEDOM\Administrator]:
				Record added successfully

Testar a resolução do registro que foi criado no passo anterior:

	# host -t A svrchat
	
		A saída desse comando deve ser parecida com essa:
		
				svrchat.freedom.local has address 192.168.2.70
				
Criar o registro do tipo "PTR" na zona reversa do DNS do SAMBA, para o próprio servidor do SAMBA (FreeBSD):

	# samba-tool dns add 127.0.0.1 2.168.192.in-addr.arpa 60 PTR svr02.freedom.local -U Administrator
	
		A saída desse comando deve ser parecida com essa:
		
				Password for [FREEDOM\Administrator]:
				Record added successfully
				
Testar a resolução reversa do registro que foi criado no passo anterior:

	# host 192.168.2.60
	
		A saída desse comando deve ser parecida com essa:
		
				60.2.168.192.in-addr.arpa domain name pointer svr02.freedom.local.
				
Criar o registro do tipo "PTR" na zona reversa do DNS do SAMBA, para o servidor que ficará hospedado o serviço do Chat xmpp/jabber Openfire:

	# samba-tool dns add 127.0.0.1 2.168.192.in-addr.arpa 70 PTR svrchat.freedom.local -U Administrator
	
		A saída desse comando deve ser parecida com essa:
		
				Password for [FREEDOM\Administrator]:
				Record added successfully
				
Testar a resolução reversa do registro que foi criado no passo anterior:

	# host 192.168.2.70
	
		A saída desse comando deve ser parecida com essa:
		
				70.2.168.192.in-addr.arpa domain name pointer svrchat.freedom.local.
				
*OBS.14: No momento de testar a resolução de nomes no modo reverso, caso apareça uma mensagem de erro parecida com essa: "Host 70.2.168.192.in-addr.arpa not found: 3(NXDOMAIN)". Verifique a zona reversa e o respectivo registro dentro da zona.

*OBS.15: Para mais informações de como administrador o DNS, acesse:

		https://wiki.samba.org/index.php/DNS_Administration
		
		https://www.samba.org/samba/docs/current/man-html/samba-tool.8.html

		https://www.mundotibrasil.com.br/gerenciando-seu-servidor-dns-pelo-shell-no-samba4/

ATENÇÃO: ATÉ AQUI SEU SERVIDOR JÁ ESTÁ COM DNS FUNCIONAL PARA QUE SE FAÇA OPERAÇÕES COM O KERBEROS. NO ENTANTO, AINDA RESTA REALIZAR AS CONFIGURAÇÕES NO ARQUIVO “krb5.conf” DO KERBEROS DENTRO DO SAMBA. PASSO QUE TAMBÉM É MUITO IMPORTANTE PARA QUE AS CONFIGURAÇÕES DE SINGLE SIGN-ON (SSO) FUNCIONEM.

=================================
CONFIGURAR O KERBEROS DENTRO DO SAMBA

Passo 18:

O arquivo de configuração do Kerberos "krb5.conf" fica localizado dentro do diretório "private" do SAMBA. Basta realizar:

			# smbd -b
	 
				Procure então pela variável "PRIVATE_DIR:" (sem aspas):

					PRIVATE_DIR: /var/db/samba4/private
		
				O comando pode ser feito desta forma também:
	
					# smbd -b |grep PRIVATE_DIR:
		
						PRIVATE_DIR: /var/db/samba4/private
	
				Ou simplesmente procure o arquivo "krb5.conf" com o "find":
	
					# find / -iname krb5.conf
		
						/var/db/samba4/private/krb5.conf

Editar o arquivo "krb5.conf"

	ee /var/db/samba4/private/krb5.conf

		Colocar as informações relativas ao REALM do seu domínio dentro do arquivo "krb5.conf":

					[libdefaults]
							default_realm = FREEDOM.LOCAL
							dns_lookup_realm = false
							dns_lookup_kdc = true
					[realms]
							FREEDOM.LOCAL = {
							kdc = svr02.freedom.local
							admin_server = srv02.freedom.local
							default_domain = FREEDOM.LOCAL
							}
					[domain_realm]
							.freedom.local = FREEDOM.LOCAL
							freedom.local = FREEDOM.LOCAL

Criar um link simbólico para o arquivo "krb5.conf" dentro do diretório "/etc/":

	# ln -s /var/db/samba4/private/krb5.conf /etc/krb5.conf
	
Verificar se o link simbólico foi criado:

	# ls -alh /etc | grep 'krb5*'
	
		A saída desse comando deve ser parecida com essa:
			
				lrwxr-xr-x   1 root  wheel       32B Aug 31 01:27 krb5.conf -> /var/db/samba4/private/krb5.conf
				
*OBS.15: Para mais informações sobre a configuração do Kerberos, acesse:
				
				https://www.h5l.org/
				
				https://web.mit.edu/kerberos/
				
				https://www.amazon.com.br/Kerberos-Definitive-Guide-ebook/dp/B004P1J81C
				
				https://books.google.com.br/books?id=dGMd-uay-lkC&pg=PT67&lpg=PT67&dq=kerberos+heimdal+definitive+guide&source=bl&ots=JvehrL37ad&sig=aYeWPh60-Ojddbliae3eTJANBBg&hl=pt-BR&sa=X&ved=2ahUKEwjRm7HynZ3dAhXLDJAKHa1mD3AQ6AEwBnoECAAQAQ#v=onepage&q=kerberos%20heimdal%20definitive%20guide&f=false
				
				https://www.safaribooksonline.com/library/view/kerberos-the-definitive/0596004036/ch04s02.html
				
				https://www.safaribooksonline.com/library/view/kerberos-the-definitive/0596004036/ch04s04.html

PASSO EXTRA 4

OBS.EXTRA.4-1: POR HORA, AS CONFIGURAÇÕES DO SERVIDOR SAMBA ESTÃO PRATICAMENTE PRONTAS, A NÃO SER POR UM DETALHE: no momento da configuração do servidor Openfire no ubuntu, quando da conexão ao diretório (INTEGRAÇÃO DO OPENFIRE AO DOMÍNIO SAMBA), nas configurações de LDAP, ao fazer o teste de conexão vai apresentar um erro que está relacionado a autenticação forte utilizada no SAMBA ("algo que define se o Servidor ldap requer que tráfego ldap traffic seja assinado ou assinado e criptografado (selado)"), a qual não é suportada pelo servidor Openfire. Para "DRIBLAR" isso, é adicionado um parâmetro dentro do arquivo de configuração do SAMBA (smb4.conf), o qual irá permitir "associação simples e SASL em todos os transportes".

OBS.EXTRA.4-2: Acontece que, "Descobriu-se que a implementação LDAP do Samba não impõe proteção de integridade para conexões LDAP. Um invasor intermediário pode usar esta falha para downgrade conexões LDAP para não utilizar proteção de integridade, permitindo que eles sequestrem tais conexões. Esta falha afeta todas funções possíveis que o Samba pode operar.". Logo, isso mexe diretamente nas questões de segurança do SAMBA.

OBS.EXTRA.4-3: LEMBRANDO QUE, A FALHA MENCIONADA AQUI, AFETA A INTEGRAÇÃO DO OPENFIRE COM O PRÓPRIO DOMÍNIO SAMBA, E POR CONSEQUÊNCIA, AS CONFIGURAÇÕES DE SSO. JUSTAMENTE PORQUE SE NÃO HÁ A INTEGRAÇÃO COM O DOMÍNIO, NÃO HÁ USUÁRIO "IMPORTADO" E COM ISSO, NÃO HÁ SENTIDO PARA SE UTILIZAR O SINGLE SIGN-ON (SSO). O QUE DEIXARIA O ADMINISTRADOR DE REDE A MERCÊ DE VÁRIOS BANCOS DE DADOS COM NOMES DE USUÁRIOS E SENHAS TOTALMENTE DIVERSOS E DISPERSOS DO DOMÍNIO, LEVANDO O CONTEXTO DE INTEROPERABILIDADE PRO ESPAÇO, ENTRE OUTRAS QUESTÕES POLÊMICAS NO SENTIDO DE FUNCIONALIDADE ESCALÁVEL DE QUE TRATA UM DOMÍNIO. AÍ FICA A PERGUNTA: E AGORA?? ENTÃO, FICA A SEU CRITÉRIO.

OBS.EXTRA.4-4: Para mais informações sobre o que foi citado acima, acesse:

		https://access.redhat.com/pt/articles/2262001




VOLTANDO AS CONFIGURAÇÕES:

Edite o arquivo "smb4.conf":

	ee /usr/local/etc/smb4.conf
	
		ADICIONE O SEGUINTE PARÂMETRO DENTRO DO ARQUIVO DE CONFIGURAÇÃO DO SAMBA (smb4.conf) na seção "[global]":
	
				ldap server require strong auth = no

SEGUE UMA CÓPIA INTEGRAL DO TRECHO NO LINK ACIMA RELACIONADO AO QUE FOI CITADO NAS OBSERVAÇÕES EXTRAS DE 4-1 A 4-3:

***"CVE-2016-2112: O cliente LDAP e servidor não impõem proteção de integridade

Descobriu-se que a implementação LDAP do Samba não impõe proteção de integridade para conexões LDAP. Um invasor intermediário pode usar esta falha para downgrade conexões LDAP para não utilizar proteção de integridade, permitindo que eles sequestrem tais conexões.

Esta falha afeta todas funções possíveis que o Samba pode operar.

O patch de recomendação de segurança para esta falha introduz uma nova opção smb.conf:

Raw
ldap server require strong auth (G)

A opção "ldap server require strong auth" define se o

Servidor ldap requer que tráfego ldap traffic seja assinado ou
assinado e criptografado (selado). Os valores possíveis são no,
allow_sasl_over_tls and yes.

Um valor de no permite associação simples e sasl em todos os transportes.

Um valor de allow_sasl_over_tls allows simples e associação sasl (sem assinatura ou selo )
nas conexões TLS criptografadas. Somente conexões não criptografadas.
permitem associações sasl com assinatura ou selo.

Um valor yes permite somente associações simples em conexões  TLS criptografadas.
Conexões não criptografadas permitem somente associações sasl com assinatura e ou selo. 

Padrão: servidor Idap requer forte auth=yes
Nota: o servidor LDAP ainda não tem uma opção para impor autenticação forte. Os patches de segurança irão introduzir uma nova opção chamada ldap server require strong auth, valores possíveis são no, allow_sasl_over_tls e yes.

Como o comportamento padrão foi estabelecido para no antes, você talvez tenha que explicitamente trocar esta opção até que todos os clientes tenham sido ajustados para lidar com erros LDAP_STRONG_AUTH_REQUIRED. Clientes Windows e os servidores membros de Samba já utilizam proteção de integridade."***


ATENÇÃO: AGORA VAMOS PARTIR PARA A CONFIGURAÇÃO DO SERVIDOR DE CHAT XMPP/JABBER OPENFIRE QUE VAI RODAR EM CIMA DO SISTEMA OPERACIONAL GNU/LINUX UBUNTU.

===============================================================================
PREPARAÇÃO DO SERVIDOR UBUNTU
COM SERVIDOR DE CHAT XMPP/JABBER OPENFIRE


PASSO EXTRA 5

CRIAR NO AD UM GRUPO SOMENTE PARA O OPENFIRE COM TODOS OS USUÁRIOS DO DOMÍNIO;

CRIAR UM USUÁRIO PARA ACESSO DO OPENFIRE;

OBS.EXTRA.5-1:: SE O USUÁRIO NÃO TIVER SIDO ADICIONADO AO GRUPO ANTES DA CONFIGURAÇÃO DO OPENFIRE, ELE NÃO VAI APARECER NO GRUPO CORRESPONDENTE DENTRO DO OPENFIRE, PARA QUE O MESMO APAREÇA, É NECESSÁRIO REINICIAR O SERVIÇO DO OPENFIRE.

IMPORTANTE: ANTES DE TUDO, CONFIGURE UM IP ESTÁTICO PARA SUA PLACA DE REDE DO SERVIDOR DE CHAT XMPP/JABBER OPENFIRE:

# nano /etc/network/interfaces

		# The primary network interface
		auto eth0
		iface eth0 inet static
		address 192.168.2.70
		netmask 255.255.255.0
		post-up route add default gw 192.168.2.1

=================================
INSTALAR PACOTES NECESSÁRIOS

Passo 19:

Adicionar repositório do Oracle Java 8:

	# add-apt-repository ppa:webupd8team/java
	
Atualizar o "apt-get":

	# apt-get update
	
Instalar o pacote Oracle Java:

	# apt-get install oracle-java8-installer
	
			IMPORTANTE: Para mais informações, acesse:
			
					http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html
					
Instalar o pacote "mysql-server":

	# apt-get install mysql-server
	
Instalar o pacote "krb5-user":
	
	# apt-get install krb5-user
	
Instalar o pacote "samba-common-bin":

	# apt-get install samba-common-bin

Baixar o pacote do openfire de acordo com a distro, pode ser o ".tar.gz":

	# wget http://download.igniterealtime.org/openfire/openfire_4_0_2.tar.gz

Se baixou o ".tar.gz" extrair o mesmo, mover a pasta openfire para dentro do diretório var ou opt:

	# cp -v openfire_4_0_2.tar.gz /opt/
	
	# cd /opt/
	
	# tar zxvf openfire_4_0_2.tar.gz
	
	# rm openfire_4_0_2.tar.gz
	
Criar um link simbólico para dentro de "/etc/init.d/":

	# ln -s /opt/openfire/bin/openfire /etc/init.d/openfire
	
Adicionar o script na inicialização do servidor:

	# update-rc.d openfire defaults

			*OBS.16:SE MESMO COM A LINHA ACIMA O SCRIPT NÃO INICIALIZAR NO BOOT, ADICIONE A LINHA ABAIXO AO arquivo "rc.local":

					/etc/init.d/openfire start
					
			*OBS.17: AINDA NÃO START O OPENFIRE.

=================================
CRIAR USUÁRIO, BANCO DE DADOS E GARANTIR PRIVILÉGIOS

Passo 20:

Adicionar um usuário chamado "openfire":

	# adduser openfire

Abrir o console do "MySQL-Server" com o usuário "root":

	# mysql -u root -p

Criar o Banco de Dados do Servidor Openfire:

	mysql> create database openfire;
	
Garantir todos os privilégios, no Banco de Dados do Servidor Openfire criado acima, ao usuário openfire:

	mysql> GRANT ALL PRIVILEGES ON openfire.* TO 'openfire'@'localhost' IDENTIFIED BY 'Pass@w0rd' WITH GRANT OPTION;
	
Confirmar privilégios:

	mysql> FLUSH PRIVILEGES;
	
Sair do console do MySQL-Server:

	mysql> exit

=================================
CONFIGURAR O KERBEROS PARA ACESSO AO KDC

Passo 21:

Entrar no diretório /etc/:

	# cd /etc/

Renomear o arquivo "krb5.conf"

	# mv krb5.conf krb5.conf.old
	
Criar outro arquivo "krb5.conf"

	# nano krb5.conf
	
		Adicionar as seguintes linhas ao arquivo "krb5.conf"
		
				[libdefaults]
						default_realm = FREEDOM.LOCAL
						kdc_timesync = 1
						forwardable = true
						proxiable = true
				[realms]
						FREEDOM.LOCAL = {
						kdc = svr02.freedom.local
						admin_server = srv02.freedom.local
						default_domain = FREEDOM.LOCAL
						}
				[domain_realm]
						.freedom.local = FREEDOM.LOCAL
						freedom.local = FREEDOM.LOCAL

=================================
CONFIGURAR AS INFORMAÇÕES DE DNS

Passo 22:

Editar o arquivo "/etc/resolv.conf":

	# nano /etc/resolv.conf
	
Adicionar ao arquivo "resolv.conf" o endereço IP do Servidor SAMBA, juntamente com o domínio pesquisável:

	search freedom.local
	domain freedom.local
	nameserver 192.168.2.60

Verificar se o DNS está fazendo resolução dos nomes dos servidores, tanto o direto, quanto o reverso:

	# host -t A svr02.freedom.local
	
	# host -t A svrchat.freedom.local
	
	# host 192.168.2.60
	
	# host 192.168.2.70

=================================
CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - PRIMEIRA PARTE

Passo 23:

Criar o arquivo "gss.conf" dentro do diretório "/opt/openfire/":

	# nano gss.conf
		
			Adicionar as seguintes linhas a esse arquivo:
			
					com.sun.security.jgss.accept {
						 com.sun.security.auth.module.Krb5LoginModule
						 required
						 storeKey=true
						 keyTab="/opt/openfire/resources/xmpp.keytab"
						 doNotPrompt=true
						 useKeyTab=true
						 realm="FREEDOM.LOCAL"
						 principal="xmpp/svrchat@FREEDOM.LOCAL"
						 isInitiator=false
						 debug=true;
					};
				
				*OBS.18: Observação aos campos "keytab", "realm" e "principal". Os valores desses campos devem ser preenchidos de acordo a configuração do servidor de chat xmpp/jabber Openfire. (caminho da chave xmpp.keytab; nome do realm em letras maiúsculas; e nome do principal, respectivamente).
				
				*OBS.19: Cabe uma ressalva importante aqui para o nome do principal. Este nome deve ser preenchido com o nome que autentica para o Kerberos no Servidor onde está o SAMBA. Para saber qual o nome correto, vai ser necessário a utilização da ferramenta ktutil e kinit (passo que vai ser visto mais à frente).
				
				*OBS.20: A criação desse arquivo não influencia em nada, neste momento, vai ser necessário, mais à frente, quando for criada chave correspondente no Console de Gerenciamento (frontend) do Openfire.
				
				*OBS.21: NESSES PASSOS DE CONFIGURAÇÃO DO SASL/GSSAPI É IMPORTANTE QUE SE TENHA O CONCEITO E NOÇÃO DO QUE É FEITO NOS "BASTIDORES". PARA MAIS INFORMAÇÕES, ACESSE:

						https://www.cyrusimap.org/sasl/
						
						https://www.openldap.org/doc/admin24/sasl.html
						
						https://www.cyrusimap.org/sasl/sasl/faqs/openldap-sasl-gssapi.html

=================================
CONFIGURAR O OPENFIRE NO CONSOLE DE ADMINISTRAÇÃO

Passo 24:

Start o Openfire:

/opt/openfire/bin/openfire start

ou

/etc/init.d/openfire start


Verificar se as portas utilizadas pelo serviço do Java no Openfire estão abertas:

	# netstat -anlp |grep 'java'
	
			A saída desse comando deve ser parecida com essa:
			
					tcp6       0      0 :::9090                 :::*                    OUÇA       5810/java
					unix  2      [ ]         STREAM     CONECTADO     17122    5810/java
					unix  2      [ ]         STREAM     CONECTADO     17119    5810/java

						IMPORTANTE: DEPOIS DE CONFIGURADO O OPENFIRE NO CONSOLE DE ADMINISTRAÇÃO, FAÇA NOVAMENTE O COMANDO ACIMA, NO ENTANTO A SAÍDA DELE DEVE SER PARECIDA COM ESSA ABAIXO:
								
									tcp6       0      0 :::5229                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5262                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5263                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::7443                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5269                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5275                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5276                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::7070                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::7777                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::9090                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::9091                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5222                 :::*                    OUÇA       1473/java
									tcp6       0      0 :::5223                 :::*                    OUÇA       1473/java

									[...]
				
								IMPORTANTE: Para mais detalhes sobre quais portas o openfire utiliza, acesse:
				
										https://discourse.igniterealtime.org/t/list-of-ports-used-by-openfire/75860/7

Verificar também se a porta do serviço do MySQL-Server está aberta:

	# netstat -anlp |grep 'mysqld'

			A saída desse comando deve ser parecida com essa:
			
					tcp        0      0 127.0.0.1:3306          0.0.0.0:*               OUÇA       1054/mysqld
					unix  2      [ ACC ]     STREAM     OUVINDO       11989    1054/mysqld         /var/run/mysqld/mysqld.sock

Acessar o openfire pelo browser na porta "9090":

	http://ipdoservidor:9090
	
Utilizar banco de dados externo:

	configurar a conexão com o mysql setando o banco criado:
	
		jdbc:mysql://127.0.0.1:3306/openfire?rewriteBatchedStatements=true
		
			Utilizar o usuário openfire e a senha criada para o mesmo.

Escolher Servidor de Diretórios (LDAP):

	Para realizar essa configurações, é ideal que vc possua os nomes distintos (essas informações podem ser resgatadas no console de gerenciamento de usuários do AD, na opção "Editor de Atributos"):
	
			DC=freedom,DC=local (DC=nomedodominio,DC=continuacaodonomedodominio)

			CN=Suporte Openfire User,OU=FREEDOM,DC=freedom,DC=local (nome distinto relativo do usuário para administração do openfire)
									
						Informção de mapeamento LDAP
						Host:	192.168.2.60
						Porta:	389
						DN Base:	DC="freedom",DC="local"
						DN Administrador:	administrator@freedom.local
						
			IMPORTANTE: PODE SER QUE APRESENTE ALGUM ERRO NA HORA DA CONEXÃO AO LDAP QUANDO FOR UTILIZAR O NOME DISTINTO RELATIVO (RDN) DO USUÁRIO. CASO POSITIVO, UTILIZE O NOME DE USUÁRIO PELO FQDN DO MESMO (suporte@freedom.local).

*OBS.22: ALGUNS FILTROS QUE PODE SE UTILIZAR:

			EM MAPEAMENTO DE USUÁRIO:

				EM CONFIGURAÇÕES AVANÇADAS, MUDAR O FILTRO DE USUÁRIO DE:

					(objectClass=organizationalPerson)

				PARA:

					(objectClass=organizationalPerson)(&(objectCategory=person)(objectClass=user)(memberOf=CN=openfire,OU=FREEDOM,DC=freedom,DC=local))


			EM MAPEAMENTO DE GRUPO:

				EM CONFIGURAÇÕES AVANÇADAS, MUDAR O FILTRO DE GRUPO DE:

					(objectClass=group)

				PARA:

					(&(objectClass=group)(|(groupType=-2147483646)))
					
			IMPORTANTE:
			
				Para que os grupos apareçam no spark, ir na interface de administração do openfire, dentro da guia grupos, selecionar o grupo desejado, "Digite o nome da lista de contatos de grupo" e marcar as opções:

						Ativar o compartilhamento de lista de contatos de grupo
						Compartilhar grupo com usuário adicionais
						Os seguintes grupos: (selecionar os grupos desejados)

				NÃO ESQUECER DE IR NA GUIA "Configurações do Servidor", na opção "Registro & Login" e desativar:

						Registro de conta via cliente
						Mudar senha
						Login Anônimo
						
				BAIXAR E INSTALAR O PLUGIN LDAP VCARD (PLUGIN PARA COLOCAR FOTO DE PERFIL NO CHAT) (basta colocar o plugin dentro da pasta "plugin" no diretório do Openfire)
				
					Ir na guia "gerenciamento do servidor", opção "propriedades do sistema":
					
						Alterar a opção "ldap.override.avatar" para "true" (sem aspas)

=================================
CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - SEGUNDA PARTE

Passo 25:

Modificar ou adicionar os valores abaixo no console de administração do Openfire, na guia "Gerenciamento do Servidor" na opção "Propriedades do Sistema":

	*OBS.23: PARA ADICIONAR NOVAS PROPRIEDADES, VÁ QUASE NO RODAPÉ DA PÁGINA E NA OPÇÃO "Adicionar nova propriedade"

	*OBS.24: Para saber mais propriedades: "https://community.igniterealtime.org/docs/DOC-1061"

			sasl.gssapi.config --> valor: /opt/openfire/gss.conf (aqui é caminho de localização do arquivo "gss.conf" criado em "CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - PRIMEIRA PARTE")
			sasl.gssapi.debug --> valor: false
			sasl.gssapi.useSubjectCredsOnly --> valor: false
			sasl.mechs --> valor: GSSAPI
			sasl.realm --> valor: FREEDOM.LOCAL
			xmpp.fqdn --> valor: svrchat.freedom.local

Restartar o serviço do Openfire:

	# /etc/init.d/openfire restart

	ou

	# /opt/openfire/bin/openfire restart

=================================
INGRESSAR O SERVIDOR DE CHAT XMPP/JABBER OPENFIRE AO DOMÍNIO SAMBA

Passo 26:

Entrar no diretório do SAMBA:

	# cd /etc/samba
	
Renomear o arquivo "smb.conf":

	# mv smb.conf smb.conf.old
	
Criar outro arquivo "smb.conf":

	# nano smb.conf
		
		Adicionar as seguinte linhas ao arquivo "smb.conf" criado acima (DE ACORDO COM O SEU AMBIENTE, NESSE ARQUIVO TEM INFORMAÇÕES DESNECESSÁRIAS):
		
				[global]
					workgroup = FREEDOM
					security = ADS
					realm = FREEDOM.LOCAL
					encrypt passwords = yes

					netbios name = SVRCHAT
					domain master = no
					host msdfs = no

					#dedicated keytab file = /opt/openfire/resources/xmpp.keytab
					kerberos method = secrets and keytab
					client signing = if_required

					## map id's outside to domain to tdb files.
					idmap config *:backend = tdb
					idmap config *:range = 50001-80000
					## map ids from the domain  the range may not overlap !
					idmap config INTERNAL:backend = ad
					idmap config INTERNAL:schema_mode = rfc2307
					idmap config INTERNAL:range = 10000-40000		

					winbind nss info = rfc2307
					winbind trusted domains only = no
					winbind use default domain = yes
					winbind enum users  = yes
					winbind enum groups = yes
					winbind refresh tickets = yes
					winbind offline logon = yes
			
			IMPORTANTE: PARA MAIS INFORMAÇÕES SOBRE O SAMBA, ACESSE:
			
				https://wiki.samba.org/index.php/User_Documentation
				
Ingressar ao domínio:

	# net ads join -U Administrator
	
Testar se foi adicionado:

	# net ads testjoin
	
Verificar as informações no domínio:

	# net ads status -U Administrator
	
		*OBS.25: DAS INFORMAÇÕES TRAZIDAS PELO COMANDO ACIMA, ESSAS SÃO AS MAIS IMPORTANTES PARA O CENÁRIO ATUAL:
		
				dNSHostName: svrchat.freedom.local
				servicePrincipalName: HOST/SVRCHAT
				servicePrincipalName: HOST/svrchat.freedom.local

					ATENÇÃO: DEPOIS DE FEITO O COMANDO DESCRITO ABAIXO (net ads keytab add xmpp -U Administrator) PARA ADICIONAR UM NOVO PRINCIPAL E GERAR A KEYTAB, REFAÇA O COMANDO ACIMA (net ads status -U Administrator), VC VERÁ QUE FOI ADICIONADO UM NOVO PRINCIPAL "XMPP" COM O HOSTNAME E O FQDN DO SERVIDOR DE CHAT, COMO A SAÍDA ABAIXO:
					
											servicePrincipalName: HOST/SVRCHAT
											servicePrincipalName: HOST/svrchat.freedom.local
											servicePrincipalName: XMPP/SVRCHAT
											servicePrincipalName: XMPP/svrchat.freedom.local
	
ADICIONAR O XMPP COMO PRINCIPAL GERANDO A KEYTAB (krb5.keytab):

	# net ads keytab add xmpp -U Administrator
	
		*OBS.26: O COMANDO ACIMA GERA A KEYTAB DENTRO DO DIRETÓRIO "/etc"

Verificar a keytab gerada:

	# klist -k
	
		A saída desse comando deve ser parecida com essa:
		
			Keytab name: FILE:/etc/krb5.keytab
			KVNO Principal
			---- --------------------------------------------------------------------------
				2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
				2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
				2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
				2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
				2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
				2 xmpp/svrchat@FREEDOM.LOCAL
				2 xmpp/svrchat@FREEDOM.LOCAL
				2 xmpp/svrchat@FREEDOM.LOCAL
				2 xmpp/svrchat@FREEDOM.LOCAL
				2 xmpp/svrchat@FREEDOM.LOCAL
				
FAZER O TESTE DE AUTENTICAÇÃO PARA O KERBEROS NESSA KEYTAB SETANDO O PRINCIPAL:

	# kinit -V -k -t /etc/krb5.keytab xmpp/svrchat.freedom.local@FREEDOM.LOCAL
	
		*OBS.27: OBSERVE QUE AQUI É UM PASSO FUNDAMENTAL PARA DEFINIR QUAL PRINCIPAL USAR NO ARQUIVO "gss.conf" CITADO NA "*OBS.19 DO Passo 23 da seção CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - PRIMEIRA PARTE".
		
		*OBS.28: SE APRESENTAR ERRO PROPOSITAL CONFORME A SAÍDA DO COMANDO ACIMA:
		
					Using default cache: /tmp/krb5cc_0
					Using principal: xmpp/svrchat.freedom.local@FREEDOM.LOCAL
					Using keytab: /etc/krb5.keytab
					kinit: Preauthentication failed while getting initial credentials
					
						BASTA VC ALTERAR O PRINCIPAL PARA QUE AUTENTIQUE PARA O KERBEROS:
						
								# kinit -V -k -t /etc/krb5.keytab xmpp/svrchat@FREEDOM.LOCAL
									
									A saída desse comando deve ser parecida com essa:
									
											Using default cache: /tmp/krb5cc_0
											Using principal: xmpp/svrchat@FREEDOM.LOCAL
											Using keytab: /etc/krb5.keytab
											Authenticated to Kerberos v5
										
												PERCEBA QUE AO ALTERAR O PRINCIPAL, ELE CONSEGUIU AUTENTICAR NORMALMENTE PARA O KERBEROS, LOGO É ESSE PRINCIPAL QUE VC DEVE COLOCAR NO CAMPO "principal" DO ARQUIVO "gss.conf" CITADO NA "*OBS.19 DO Passo 23 da seção CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - PRIMEIRA PARTE".

=================================
CONFIGURAR AS INFORMAÇÕES DE SASL/GSSAPI PARA REALIZAR SSO - TERCEIRA PARTE

Passo 27:

Com o auxílio da ferramenta "ktutil", vc vai ler a keytab local "/etc/krb5.keytab" e gerar nova keytab no diretório do Openfire "/opt/openfire/resources":

	# ktutil
	
		Ler a keyTab dentro do console do ktutil:

			ktutil:  rkt /etc/krb5.keytab
		
		Listar a keytab somente para confirmar se é a mesma que foi utilizada para verificar e gerar o ticket do principal:
		
			ktutil:  l
			
				A saída desse comando deve ser parecida com essa:
				
						slot KVNO Principal
						---- ---- ---------------------------------------------------------------------
							1    2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
							2    2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
							3    2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
							4    2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
							5    2 xmpp/svrchat.freedom.local@FREEDOM.LOCAL
							6    2               xmpp/svrchat@FREEDOM.LOCAL
							7    2               xmpp/svrchat@FREEDOM.LOCAL
							8    2               xmpp/svrchat@FREEDOM.LOCAL
							9    2               xmpp/svrchat@FREEDOM.LOCAL
						   10    2               xmpp/svrchat@FREEDOM.LOCAL
						   
				IMPORTANTE: ANTES DE ESCREVER UMA NOVA KEYTAB COM TODAS ESSA INFORMAÇÕES, VC PODE REMOVER OS SLOTS COM OS PRINCIPAIS QUE NÃO AUTENTICARAM PARA O KERBEROS ATRAVÉS DO COMANDO "delent" seguide espaço e o número do slot correspondente. No caso desse cenário que montei, os slots que poderiam ser apagados, seriam os de 1 a 5.
		
		Escrever nova keytab no diretório do Openfire "/opt/openfire/resources":
		
			ktutil:  wkt /opt/openfire/resources/xmpp.keytab
			
				IMPORTANTE: CASO QUEIRA TER CERTEZA DE QUE ESCREVEU A NOVA KEYTAB COM AS INFORMAÇÕES CORRETAS, BASTA LER ESSA KEYTAB QUE FOI GERADA (rkt /opt/openfire/resources/xmpp.keytab) E DEPOIS MANDAR LISTAR (list) O CONTEÚDO DA MESMA.
				
		SAIR DO CONSOLE DA FERRAMENTA "ktutil":
		
			ktutil:  q
			
MODIFICAR AS PERMISSÕES DA KEYTAB QUE FOI GERADA NO DIRETÓRIO DO OPENFIRE:

	# chmod 755 /opt/openfire/resources/xmpp.keytab
	
REINICIAR O SERVIÇO DO OPENFIRE:

	# /opt/openfire/bin/openfire restart

ATENÇÃO: ATÉ AQUI O SEU SERVIDOR DE CHAT XMPP/JABBER OPENFIRE NO SISTEMA OPERACIONAL UBUNTU JÁ É CAPAZ DE UTILIZAR O KERBEROS PARA REALIZAR CONEXÕES AO SERVIDOR SAMBA NO SISTEMA OPERACIONAL FreeBSD. AGORA VAMOS PARTIR PARA A CONFIGURAÇÃO DO(S) HOST(S) QUE UTILIZARA(ÃO) O CLIENTE SPARK PARA FAZER SINGLE SIGN-ON (SSO) NO SISTEMA OPERACIONAL WINDOWS.

===============================================================================
PREPARAÇÃO DOS HOSTS (MÁQUINAS CLIENTES) WINDOWS
PARA A UTILIZAÇÃO DO CLIENTE DE CHAT XMPP/JABBER SPARK EM SSO

Passo 28:

*OBS.29: É IMPORTANTE QUE PARA ESTE PASSO OS HOSTS (MÁQUINAS CLIENTES) WINDOWS JÁ ESTEJAM INGRESSADOS AO DOMÍNIO. PORTANTO, COM AS INFORMAÇÕES DE MÁQUINA DO DOMÍNIO, ISSO INCLUI QUE O DNS PRIMÁRIO SEJA O ENDEREÇO IP DO SERVIDOR SAMBA (BIND/SAMBA). CASO CONTRÁRIO, NÃO VAI FUNCIONAR.

*OBS.30: É IMPORTANTE TAMBÉM QUE SE FAÇA TESTES DE RESOLUÇÃO DE NOMES COM A FERRAMENTA "nslookup", PARA SABER SE ESTÁ RESOLVENDO O DIRETO E O REVERSO DOS SERVIDORES SAMBA E CHAT OPENFIRE DE DENTRO DOS HOSTS (MÁQUINAS CLIENTES). CASO NÃO ESTEJA RESOLVENDO, NÃO VAI FUNCIONAR.

*OBS.31: É IMPORTANTE TAMBÉM QUE OS RELÓGIOS DOS SERVIDORES E HOSTS (MÁQUINAS CLIENTES) ESTEJAM SINCRONIZADOS, OU COM UMA DIFERENÇA DE NO "MÁXIMO" 5 MINUTOS, PRA MAIS OU PRA MENOS, DE UM PRO OUTRO. CASO CONTRÁRIO, NÃO VAI AUTENTICAR PARA O KERBEROS.

Instalar o java para windows.

Instalar o cliente de chat xmpp/jabber Spark:

	*OBS.32: RECOMENDA-SE, ATÉ ENTÃO, A VERSÃO 2.7.7 DO SPARK.
	
Criar a chave "AllowTGTSessionKey" no registro do Windows:

	Esse parâmetro deve ser adicionado ao seguinte caminho:

		Computador\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
	
			(Novo > Valor DWORD (32 bits)) ou (REG_DWORD) = 1

				*OBS.33: O parâmetro "AllowTGTSessionKey" é para o java ter permissão de leitura ao ticket do kerberos na sessão atual; caso não esteja adicionado ao registro do windows, o spark não vai conseguir determinar o FQDN do usuário, apresentando a mensagem: "Unable to determine".

Criar o arquivo "krb5.ini" dentro do diretório "C:\Windows" com o seguinte conteúdo:

	[libdefaults]
			 default_realm = FREEDOM.LOCAL
	[realms]
			 FREEDOM.LOCAL = {
             kdc = svr02.freedom.local
             admin_server = srv02.freedom.local
             default_domain = FREEDOM.LOCAL
			 }
	[domain_realm]
			 .freedom.local = FREEDOM.LOCAL
			 freedom.local = FREEDOM.LOCAL
			 
IMPORTANTE: ATÉ AQUI, SE NÃO OCORREU NENHUM ERRO (CASO TENHA OCORRIDO, VOLTE NA PARTE QUE OCORREU E VERIFIQUE SUAS CONFIGURAÇÕES), OS SEUS HOSTS JÁ ESTÃO COM QUASE TODA A CONFIGURAÇÃO PRONTA PARA REALIZAR SSO NO SPARK. NO ENTANTO, RESTAM MAIS DOIS PASSOS:

	Passo 29:
	
		No Spark, na tela de login, guia "avançado", na guia "SSO" marque "Use Single Sign-On (SSO) via GSSAPI". Em "Preferências Avançadas de Conexão", marque qualquer uma das três alternativas (Use krb5.conf or krb5.ini; Use DNS; Specify below).
			
				No caso de utilizar a opção "Specify below", no campo "Realm", deve ser digitado o nome do REALM do Kerberos em letras maiúsculas e no campo "KDC", deve ser digitado o FQDN em letras minúsculas ou o endereço IP do servidor SAMBA, no caso deste ambiente, ficaria "FREEDOM.LOCAL" e "svr02.freedom.local" (todos sem aspas).
		
					Volte para a tela de login e perceba que ele já pegou automaticamente as informações de usuário logado, basta apenas digitar o endereço do servidor de chat xmpp/jabber Openfire no campo "servidor" abaixo do campo "Account:":
					
							Este nome pode ser tanto o FQDN, o Hostname ou endereço IP do servidor de chat xmpp/jabber Openfire:
								
									svrchat.freedom.local
									
									ou
									
									svrchat
									
									ou
									
									192.168.2.70

PASSO EXTRA 6

MELHORES PRÁTICAS PARA CONFIGURAR O SPARK (PARA ELE FICAR MAIS ATRATIVO PARA O USUÁRIO):

**NA GUIA CONTATOS MARCAR AS OPÇÕES:
	mostrar grupos vazios
	show offline users

**NA GUIA FILE, OPÇÃO PREFERÊNCIAS:
	CHAT EM GRUPO, MARCAR:
		Show toast popup when someone says my name

	SONS, MARCAR "TOCAR SONS..." EM TODAS AS OPÇÕES

	APARÊNCIA, MARCAR:
		Mostrar Avatar na lista de contatos

	NOTIFICAÇÕES, MARCAR:
		Mostrar Popup estilo torradeira
		Notificar quando usuário ficar offline (aumentar tempo para 3 segundos)
		Notificar quando usuário ficar online
		Show new messages in the system tray

	SPELLCHECKER, MARCAR:
		Enable Spellchecking
		Enable Auto Spellchecking
		Language - Português-Brasil

*OBS.34: AS INFORMAÇÕES CITADAS NO “PASSO 29” E NO “PASSO EXTRA 6” PODEM SER ADICIONADS VIA SCRIPT DE CONFIGURAÇÃO AUTOMATIZADOS POR GPO NO SAMBA. INCLUSIVE JÁ CRIEI ESSES SCRIPTS E VOU DISPONIBILIZÁ-LOS TAMBÉM.

Passo 30: REINICIAR OS HOSTS (MÁQUINAS CLIENTES) PARA QUE AS CONFIGURAÇÕES DE SINGLE SIGN-ON (SSO) ENTREM EM VIGOR NO PRÓXIMO LOGON DO WINDOWS.

================
END OF FILE - GRAÇAS A DEUS TUDO CERTO!!!

FEITO, ESCRITO E TESTADO POR RICARDO XERFAN. DATA: 02/09/2018 - MACAPÁ-AP.

Uma dúvida, Ricardo…
Eu consigo acessar o spark fora da minha rede local, com estas configurações ?

Bom dia!

Consegue acessar tranquilamente, desde que o acesso ao seu servidor esteja devidamente configurado e liberado para conexões de fora da sua rede local. Vc pode fazer via VPN, DDNS ou se vc tiver um IP válido (público) também é válido. Sempre com a ressalva de que o seu Firewall esteja em funcionamento perfeito.

1 Like