Oneidentity Active Roles - Mover usuarios a localización correcta

 

Hola, 

Tras reducir al máximo y optimizar un workflow a través del cual, movemos usuarios a la OU correcta, partiendo de diferentes attributos, he dejado un proceso realmente limpio.

Los usuarios cuentan con información en los atributos siguientes:

• PhysicalDeliveryOfficeName -lo que es lo mismo que el campo Oficina en la creación de usuarios en AD-
• Utilizamos el atributo ExtensionAttribute1 para normalizar la familia del puesto de trabajo.

En próxima entrada os enseñaré como realizar el segundo puesto, ya que utilizo un archivo puente para asociar un buen número de empleos en una OU por ejemplo llamada Cocina u otra por ejemplo llamada Dirección.

Vale la pena indicar, que la creación de usuarios es automática mediante Active Roles Sync, proveniendo estos de una consulta SQL sobre la BD del software de recursos humanos, lo que nos lleva a crear, modificar y borrar usuarios usuarios diariamente tras detectar estos procesos en la BD.

Descripción

1. Primeramente, en este cliente hemos creado una estructura de localizaciones, cada una de ellas tiene una OU que coincide literalmente con el nombre del campo Oficina que tiene el usuario.

OU="Oficina de Alicante"   -  Usuario/atributo PhysicaldeliveryOfficeName/Oficina de Alicante

2. Seguidamente, los usuarios tienen en su atributo extensionattribute1, la familia del trabajo que desempeñan.

OU="Cocina" - Usuario/atributo ExtensionAttribute1/Cocina

3. Lo anteriormente explicado, nos permite saber que el usuario debe ir a 

OU=extensionattribute1,OU=PhysicaldeliveryofficeName,OU=Centros,OU=Usuarios,CN=dominio,CN=local

Ingenioso, ¿cierto?.

4. Lo siguiente es crear un Workflow, que se dispare, nada más se crea un usuario, o se le cambia uno de estas dos atributos, para recolocar al usuario.

    El Workflow tendrá un simple paso del tipo Move Object y en Destination Container, haremos la regla que veis en a captura, la cual generará un texto en la función rellenando los campos variables con el contenido del usuario.

Extraer Chats y contenido de Teams en auditoría.

 

Hola, 

Para extraer el contenido de chats de Teams de usuarios, tenéis que realizar los siguientes pasos:

1. Portal.office.com / Compliance / Búsqueda de contenido.

2. Crear nueva búsqueda

3. Activar Buzones de Exchange (Chat de Teams se almacena en el buzón de Exchange).

4. Usar la query: kind:im AND kind:microsoftteams y a ser posible reducir la búsqueda con condición de fecha.

Descargar el resultado.

Azure AD Connect Health - Monitorizar Windows Active Directory

 

Hola, 

Azure AD Connect health, es un servicio ofrecido en Azure que monitoriza tres escenarios y servicios diferentes. 

Los servicios que podemos monitorizar con Azure Ad Connect Health, son; 

• Sync services: Esto es la sincronización que nos proporciona AdConnect como servicio MIM entre Active Directory Domain Services (ADDS, no confundir con Azure Active Directory Domain Services AADDS)  y Azure AD.
• AD FS Services: Este agente es el ideal para monitorizar el servicio ADFS, si cuentas con él en tu organización.
• AD DS Services: Este agente monitorizará nuestro Windows Active Directory Clásico y es el que veremos hoy como poner en marcha.

En esta entrada, os hablaré de la monitorización desde Azure AD Connect Health  ADDS.

Requisitos

• Instalar un agente, requiere una licencia Azure AD P1 o superior
• Instalar un segundo agente, requiere 25 licencias Azure AD P1 o superior (en total 26).
• Resto de agentes, requieren 25 licencias Azure AD P1 o superior, cada uno de ellos.
• Cuenta Azure AD con role de administrador de identidad
• La cuenta es desechable una vez se haya instalado el agente.
• Cuenta con privilegios de administrador en la máquina en la que se ha va a instalar el agente
• Equipos con agente, requieren salida a internet.
• La versión última, lanzada de agente solo requiere puerto 443. Ya no se requiere el puerto 5671 como aparece en la documentación.
• Salida de internet a estas URls:
• login.microsoftonline.com
• secure.aadcdn.microsoftonline-p.com
• login.windows.net
• aadcdn.msftauth.net
• Powershell 5.0 o superior.
• Inspección TLS con inspección deshabilitada en la salida a internet.
• Servidor Windows Server excepto Windows Server Core.

Actualización y mantenimiento

En cuanto al mantenimiento. El agente se auto actualizará, con cada versión. 

Instalación 

• Instalación desatendida, la podéis ver en el siguiente link

• Configuración de salida a través de Proxy, la podéis ver en el siguiente Link

Proceso de instalación manual

1. El agente lo podéis descargar desde vuestro tenant y este link

2. Una vez tengáis este agente descargado y copiado en el servidor donde lo vais a instalar, el proceso de instalación es el siguiente:

Llegado este punto, tendréis que validaros en Azure AD con la cuenta creada con privilegios indicados en los requisitos.

Monitorización de resultado en consola

Comprobación de funcionamiento

Comando de powershell:  Test-AzureADConnectHealthConnectivity -Role ADDS

Saludos

Common problems publishing an app with Verified publisher

 

As Microsoft explain here.

Publisher verification gives app users and organization admins information about the authenticity of the developer's organization, who publishes an app that integrates with the Microsoft identity platform.

When an app has a verified publisher, this means that the organization that publishes the app has been verified as authentic by Microsoft. Verifying an app includes using a Microsoft Cloud Partner Program (MCPP), formerly known as Microsoft Partner Network (MPN), account that's been verified and associating the verified PartnerID with an app registration.

Keep in mind that the verified publisher is always a business who is part of the Microsoft Partner ecosystem and also, behind the MPN partnering there is, at least, an Azure tenant.

My post of today collects and explains you how to solve every problem that can appear during the process of getting the blue verified badge indicating the trusted publisher of the app.

This is the representation of the steps you have to keep for getting the registration made successfully. The known problems (in red) are explained below in this article:

Some obstacles that I usually find are so common in the scenario:

1. Lot of times you are publishing an app from different tenant that is associated to the MPN, may be from a tenant of your developers.

2. The above situation leads us to deduce that the domain filled in the MPN partnering as an email contact of your business, is not added in the secondary tenant too. Because a domain is only able to be added in one tenant as a custom domain. therefore. the domain .onmicrosoft.com cannot be used in this process and this domain cannot be the domain of the user who makes the registration (Problem in the steps 2 & 4).

3. Sending an invitation as guest is some times complicated, because the identity that you want to invite, doesn't has a mailbox and the invitation is sent as email. 

The ways to get over the difficulties shown above are:

1. You decide don't make the registration from the main tenant, it needs you to add this second tenant in the MPN Center.

2. You have to verify the domain used in the mail contact filled in MPN Partner Center- organization  profile - Legal Info using a microsoft-identity-association.json 

And the user who makes the registration needs to be a user with a custom domain, in the login name.  So you have to add a custom domain in your tenant previously. 

Example.: user@contosoapp.onmicrosoft.com is not allowed.

It fix this problem: 

The target application's Publisher Domain (publisherDomain) either doesn't match the domain used to perform email verification in Partner Center (pcDomain) or has not been verified. Ensure these domains match and have been verified then try again.

3. After the invitation to a guest has been sent, you are able to get the link that has to be accepted, going to the guest object, and clicking on the Resend Invitation.

For more information: Troubleshoot publisher verification - Microsoft Entra | Microsoft Learn

I hope it helps you.

Planificación y características avanzadas Azure AD APP Proxy

 Hola, 

A través de este artículo, voy a recopilar toda la información importante a tener en cuenta sobre el conector y escenario a construir con Azure AD Application Proxy.

Planificación e instalación

• Requisito en cuanto a licenciamiento Azure AD P1
• Requisito de entorno entorno AD sincronizado a través de AD Connect.
• Windows Server 2012 R2 o superior
• En cuanto a requisito de capacidades en el sevidor, tenéis aquí el capacity planner:
• https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-connectors#capacity-planning
• El conector, se puede instalar en un servidor en Workgroup. No obstante, si queremos tener Single Sign On, tenemos que tener el equipo en dominio con el fin de poder hacer Kerberos Constrained Delegation.
• Comando para desplegar el conector de forma silenciosa: AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
• Comando para registrar el conector de forma silenciosa: 
• $User = "<username>"
• $PlainPassword = '<password>'
• $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
• $cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $SecurePassword
• .\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred -Feature ApplicationProxy
• El servidor puede estar en un dominio que tenga relación de confianza con otro e incluso con solo acceso a un Read Only Domain Controller.
• Es importante instalar Azure AD APP proxy procurando una muy buena comunicación con las aplicaciones internas que publicará (Network topology considerations for Azure Active Directory Application Proxy - Microsoft Entra | Microsoft Learn)
• Además puedes tener un número ilimitado de Azure AD App proxy conectors que puedes organizar en grupos y estos estar ubicados en diferentes redes (buenas prácticas)
• Publish apps on separate networks via connector groups - Azure Active Directory - Microsoft Entra | Microsoft Learn
• No instales Azure AD App proxy en el mismo servidor que hayas instalado Azure AD Password Protection
• Las identidades que vayan a validarse localmente y las que vayan a validarse en cloud, han de estar sincronizadas vía AD Connect.
• En Windows Server 2019, tras la instalación de Azure APP proxy has de lanzar estos comandos: 
• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]  "EnableDefaultHTTP2"=dword:00000000
• Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0
• TLS 1.2 ha de estar habilitado en el servidor, previamente a la instalación de Azure AD Application proxy: 
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
• reiniciar el servidor.
• Azure AD App Proxy connector, necesita conectividad a internet:
• Puertos 80 y 443.
• URLS a los que ha de poder acceder:
• Opción 1: Lista de URLS: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-add-on-premises-application#allow-access-to-urls
• Opción 2 generalista: Podrías abrir un poco el foco permitiendo acceso a urls: *msapproxy.net y *.servicebus.windows.net.
• Si tienes un proxy, revisa la documentación de plataformado de proxies para Azure ADD application proxy: Work with existing on-premises proxy servers and Azure Active Directory - Microsoft Entra | Microsoft Learn
• El DNS de la empresa ha de poder resolver nombres de las URLS aparecidas en opción generalista
• Instala más de un Azure AD App Proxy en tu entorno para proveer al sistema de HA y englóbalos en un grupo. Publish apps on separate networks via connector groups - Azure Active Directory - Microsoft Entra | Microsoft Learn
• Trata de publicar cada Azure AD App Proxy Connector detrás de una salida a internet distinta para evitar un punto de fallo
• Cada conector está limitado a 200 salidas concurrentes

• Evita en los firewalls inspección de tráfico TLS en las salida de los servidores con el conector instalado.
• Si vas a querer publicar la aplicación con un dominio propio, aplicando así una capa de validación Azure AD, has de tener en cuenta lo que MSFT indica en este artículo: Custom domains in Azure Active Directory Application Proxy - Microsoft Entra | Microsoft Learn
• En un entorno multi forest y multi dominio, hay que instalar un Azure AD App Proxy connector en cada bosque.
• Puedes apuntar un connector a una web balanceada con un balanceador Layer 4 y si la web no requiere validación, puedes incluso no contar con persistencia en el balanceo. Incluso podéis usar Round Robin.
• Puedes recopilar todo el log en "Analytics" Collect Windows event log data sources with Log Analytics agent in Azure Monitor - Azure Monitor | Microsoft Learn
• por defecto, tienes los logs en Azure AD Sign in and Login Logs.
• En un escenario global, podrías añadir un Azure Traffic manager a  dos conectores en dos sedes distantes. Add your own Traffic Manager to Application Proxy - Microsoft Entra | Microsoft Learn

• En linea con lo anterior, también podemos utilizar Azure Front Door para cachear contenido.
• Using Azure Front Door to provide geo-acceleration - Microsoft Entra | Microsoft Learn

• En línea también con la hibridación con servicios Azure, podemos publicar nuestra app a través de Azure Waf: 

Mantenimiento y Remediación

• Ante una situación donde el conector, esté sin internet un tiempo, puede pasar que aparezca un error por certificado caducado, en este caso podrás reinstalar el conector o lanzar los siguientes comandos:
• Import-module AppProxyPSModule
• Register-AppProxyConnector -EnvironmentName "AzureCloud"
• Has de garantizar que el servicio Azure AAD Application proxy connector Updater está iniciado para garantizar siempre la última versión del producto.
• Aquí tienes la relación de versiones: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-faq#why-is-my-connector-still-using-an-older-version-and-not-auto-upgraded-to-latest-version-

• Aquí tenéis el directorio de posibles errores y soluciones a problemas conocidos: Troubleshoot Azure Active Directory Application Proxy - Microsoft Entra | Microsoft Learn
• Es posible mover las aplicaciones publicadas por un conector a otro. Tenéis el Powershell para realizar esta acción aquí: PowerShell sample - Move Azure Active Directory Application Proxy apps to another group - Microsoft Entra | Microsoft Learn

En próximas entradas, hablaremos sobre la validación SSO.