mercoledì 27 giugno 2018

VMware Identity Manager 2.9 – Could not Pull the Required Object From Identity Manager

Disclaimer: Some of the procedures described below is not officially supported by VMware. Use it at you own risk.

Problema
Sono stato contattato da un cliente perché l'Identity Manager che avevo messo in piedi un pò di tempo fa, sembra non autenticare più correttamente gli utenti. Sembra che l'IDM non contatti più i Domain Controllers.
Effettuato il login come utente amministratore all'interno dell'Appliance IDM (nel mio caso l'IDM è una versione 2.9.2.0 Build 6095217) vado a verificare sotto la tab Identiry & Access Management i Directories e noto che a fianco del bottone Sync Now nella riga corrispondente del Directory Name interessato c'è una X rossa che indica che l'IDM non riesce correttamente a sincronizzarsi/contattare l'AD (Active Directory).
Clicco quindi sul Sync Now  e vado a verificare in Sync Log cosa sta succedendo; il seguente messaggio di errore:

Could not pull the required object from Identity Manager


Ci si connette in SSH sull'Identity Manager cercando di reperire maggiori info dai file di logs. 
I file di logs per quello che riguarda l'vIDM sono nella directory "/opt/vmware/horizon/workspace/logs/"  nello specifico ho trovo alcune informazioni interessanti nel file di log connector.log (vedi sotto)

2018-06-20 14:11:28,514 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving config for 3002@WSIDM to file /usr/local/horizon/conf/states/WSIDM/3002/config-state.json 2018-06-20 14:11:28,521 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving state config to disk DONE. 2018-06-20 14:12:26,057 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.utils.RestClient - END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/jersey/manager/api/connectormanagement/directoryconfigs/19321c7b-0172-4eaa-89b4-c54a316a4514/syncprofile, ..., application/vnd.vmware.horizon.manager.connector.management.directory.sync.profile+json, GET, null, ...) 2018-06-20 14:12:26,057 WARN  (Timer-18) [3002@WSIDM;; com.vmware.horizon.engine.ObjectPullEngine - Code from Service :-404 2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Error message from Service :-Request timed out..[response-Request timed out. 2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Could not retrieve required object from Horizon com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon         at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)         at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)         at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)         at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)         at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)         at java.util.TimerThread.mainLoop(Timer.java:555)         atjava.util.TimerThread.run(Timer.java:505) 2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.ScheduleService - Sync of Directory aborted.com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon<         at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)         at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)         at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)         at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)         at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)         at java.util.TimerThread.mainLoop(Timer.java:555)         at java.util.TimerThread.run(Timer.java:505) 2018-06-20 14:12:26,060 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -BEGIN sendRequestBase (https://wsidm.< NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-urlencoded, GET, null, ...) 2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.mvc.UIAlerts - Could not pull the required object from Identity Manager. Request timed out..[response-Request timed out.] 2018-06-20 14:12:26,060 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.SyncScheduleService - Directory sync method: end. 2018-06-20 14:12:26,070 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-ur lencoded, GET, null, ...)
Noto una entry con "Could not retrieve required object from Horizon", il che mi fa pensare a qualche cambiamento di cui non sono a conoscenza :-) ..... googlando un pochino la stringa presente nell'interfaccia web "Could not Pull the Required Object From Identity Manager" vedo che non sono l'unico con il problema e trovo un interessante post di Matt Allfrod a questo link .

Chiedo quindi al cliente se ci sono cambiamenti con i Domain Controllers e scopro che uno di questi è stato spento (perché dismesso).

L'Identity Manager una volta configurato non effettua automaticamente delle query per verificare quali sono i Domain Controllers disponibili, ma fa riferimento ad un file "domain_krb.properties" creato in fase di configurazione.

Documentazione ufficiale VMware nell'area Integrazione con Active directory


Individuato il nome del DC dismesso procediamo alla modifica manuale del fie domain_krb.properties nel modo seguente:

1. effettuare il login all'interno dell'vIDM (Utilizzare sshuser e poi diventare root)

2. effettuare una copia del file originale 
cp /usr/local/horizon/conf/domain_krb.properties  /usr/local/horizon/conf/domain_krb.properties .ORIG

3.editare il file vi /usr/local/horizon/conf/domain_krb.properties

4. effettuare le modifiche in base ai cambiamenti dei Domain Controller e salvare le modifiche. Nel nostro caso eliminare la entry del DC che non esiste più.

5. cambiare l'ownership del file eseguendo 
chown horizon:www /usr/local/horizon/conf/domain_krb.properties

6. riavviare il servizio eseguendo service horizon-workspace restart

7. lanciare un Sync Now per verificarne il corretto funzionamento.

Con mia sorpresa mi accorgo che la procedura appena indicata non ha sortito effetto, il problema è ancora lì ed l'vIDM continua a non sincronizzarsi correttamente con l'infrastruttura Active Directory.


Soluzione
Analizzando in modo più approfondito i file di logs del connector ed ispirato dalla KB2145438 ho notato che tutte le richieste effettuate sembrano essere iniziate da un initiator (nel mio caso 3002@<nome server>) che ha un file di configurazione posizionato in /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json (vedi sopra riga 1 nel file di log).

Verificando il contenuto del file config-state.json, riscontro che ci sono delle entry con il nome del Domain Controller dismesso. 


Decido quindi di procedere come d seguito...

8. effettuare una copia del file  sorgente (prima di effettuare qualsiasi modifica) nel modo seguente... cp /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json.ORIG

wsidm:~ # cp /usr/local/horizon/conf/states/WSIDM/3002/config-state.json /usr/local/horizon/conf/states/WSIDM/3002/config-state.json.ORIG


9. sostituisco il nome del DC dismesso con uno esistente sed -i 's/<DC Vecchio>/<Nuovo DC>/g' /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json

wsidm:~ # sed -i 's/sgrsodc2017/sgrbodc2/g' /usr/local/horizon/conf/states/WSIDM/3002/config-state.json

10. riavviare il servizio eseguendo service horizon-workspace restart 


11. lanciare un Sync Now per verificarne il corretto funzionamento



12. Verificare l'accesso con una utenza di servizio. Avendo utilizzato un DC prossimo all'vIDM, a sensazione (non avendolo monitorato) la procedura di autenticazione è sembrata più veloce.


Conclusione

Consiglio di verificare tutti gli step indicati, sia per modificare il file  domain_krb.properties (eliminando i DC non più presenti) e sostituendo le entry del DC dismesso all'interno del file config-state.json con con un DC in cui è abilitata la ricerca della Posizione servizio DNS (record SRV) come indicato qui 

lunedì 11 giugno 2018

MAC - Installare PowerCLI

Nel precedente post abbiamo installato la "PowerShell" su mac, siamo quindi pronti per poter procedere con l'installazione della PowerCLI VMware.

Apriamo il terminale ed accediamo alla PowerShell digitando:

LIF:~ Lorenzo$ pwsh

Possiamo procedere con l'installazione della PowerCli VMware semplicemente digitando:

PS /Users/lorenzo> Install-Module -Name VMware.PowerCLI -Scope CurrentUser  

e confermare con "Y" per procedere con il download e l'installazione dei vari moduli..... per verificare che siano stati correttamente installati lanciare il comando ...

PS /Users/lorenzo> Get-Module -Name VMware.* -ListAvailable

Tutto sembra essere stato installato correttamente. Siamo pronti per poter utilizzare la PowerCLI su nostro macOS.


Alcuni link utili: 
https://ithinkvirtual.com/2018/03/04/install-powershell-and-vmware-powercli-on-centos/
https://blogs.vmware.com/PowerCLI/2018/03/installing-powercli-10-0-0-macos.html
https://notesfrommwhite.net/2018/02/28/installing-powershell-powercli-on-a-mac/



MAC - Installare PowerShell Core

Abbiamo precedentemente installato il tool (homebrew) necessario per procedere con l'installazione della PowerShell Core come indicato da documentazione Microsoft.

La successiva componente che dobbiamo installare per poter installare PowerShell e successivamente la PowerCLI, è Homebrew-Cask. Procediamo come indicato di seguito:


LIF:~ Lorenzo$ brew tap caskroom/cask


e continuiamo con l'installare la PowerShell

LIF:~ Lorenzo$ brew cask install powershell

Se tutto è andato correttamente ....



Verifichiamo che tutto funzioni correttamente lanciando il comando ...

LIF:~ Lorenzo$ pwsh

Come possiamo vedere la PowerShell installata in questo caso è la v6.0.2, tuttavia per avere maggiori dettagli sulla PowerShell installata possiamo digitare direttamente dal prompt della pwsh:


PS /Users/lorenzo> $PSVersionTable 


Verifichiamo i moduli installati di default 

PS /Users/lorenzo> Get-Module * -ListAvailable




Nel prossimo post procederemo con l'installazione della PowerCli VMware.

venerdì 8 giugno 2018

MAC - Installare Homebrew

Problema
Ho la curiosità e la necessità di installare "PowerShell" e la PowerCLI VMware su macOS.

Soluzione
Per prima cosa (come prima componente), se non presente nel proprio sistema, installare Homebrew. Homebrew è una delle soluzioni più diffuse su macOS per la gestione dei pacchetti.

L'installazione è molto semplice si tratta di aprire un "Terminale" e di lanciare il comando riportato sotto...

LIF:~ Lorenzo$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Procedere premendo Invio


Inserire la password e premere Invio per continuare 




Sembra che tutto si sia installato correttamente (Installation succesful). Possiamo procedere con l'installazione della PowerShell Core.


mercoledì 6 giugno 2018

LUN ID 256 missing on VMware


Problema
Creato una nuova LUN con ID 256 da Pure Storage e mappata all'Host Group degli Host VMware, non viene vista VMware. La versione degli host ESXi sono 6.5.

Di seguito si vede la nuova LUN Vol07 (ID 256) aggiunta all'host group.

Effettuato il rescan dell'HBA lato VMware, la LUN non appare nella lista di quelle raggiungibili/disponibili.


Ho quindi verificato nel configuration maximum di VMware se presenti dei limiti per la 6.5. Con sorpresa scopro che il limite per il LUN ID è 16383 (vedi immagine sotto - pag.13 del documento indicato in precedenza).





Soluzione
Il problema è stato risolto come anche indicato da Cody Hosterman andando ad associare alla LUN un ID inferiore al 256 (nel mio caso era disponibile il 246).

Quindi procediamo per step:

  • Rimuovere la LUN dall'Host Group.
  • Ri-Assegnare la LUN all'Host Group, questa volta sostituendo la dicitura "automatic" con il valore desiderato. Nel mio caso LUN ID 246 e confermando l'operazione premendo sul bottone "Confirm"


  • Accedere all'Host ESXi effettuare il Rescan delle LUN e verificare che la LLUN sia presente in lista (come possiamo vedere sotto)