AzureMfaNpsExtnConfig.ps1 Setup Unable to grant certificate private key access to NETWORK SERVICE.

 Hola, 

Durante la instalación del complemento para Azure AD en NPS, me he encontrado el error: Unable to grant certificate private key access to NETWORK SERVICE.

Esto aparece cuando la instalación del complemento se realiza en un sistema operativo con idioma distinto al inglés, ya que el servicio no se llama "Network Service" sino que en en el caso del castellano, se llama "Servicio de red".

La solución ha sido tener que modificar el script en la linea donde la variable $user adquiere el valor "Network service".

Error:

Solución 1:

También podéis ir al almacén de certificados y dar permisos de control total sobre el certificado al usuario "Servicio de red" en el equipo local.

Error cuenta Local Admin en Disjoin de equipo Azure AD

 

Hola, 

Aunque este problema estoy seguro que tendrá corto recorrido, he encontrado problemas en el "disjoin" de equipos ligados a directorios Azure AD.

En concreto, devuelve un error tras solicitar e introducir correctamente, una cuenta local de administrador.

Solución

Curiósamente el error se arregla al renombrar el equipo con el nombre que tenía originalmente e introducir de nuevo la cuenta con el formato nombreoriginaldeequipo\usuarioADMLocal.

Para poder saber el nombre original del equipo, tenéis que ir a la ruta Equipo\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SchedulingAgent donde encontraréis una entrada de nombre "Oldname" y allí el valor será el nombre con el que tenéis que renombrar el equipo.

Problema instalando el módulo nuget

 

Install-Module -name powershellget -Force

O

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Problema:

WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.

WARNING: Unable to download the list of available providers. Check your internet connection.

Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package provider requires 

'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.

At line:1 char:1

+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception

    + FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider

Solución

Lanzar en powershell: [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Problar luego a lanzar los mismos comandos.

Azure AD SSO con PCs corporativos en entorno híbrido

Hola, 

Os voy a detallar los pasos a seguir en vuestro entorno de Active Directory On premises, para, validándoos con usuarios de Active Directory, tener single sign on en el acceso web a cualquier aplicación incluida en Azure AD, como O365 nativamente, pero también con aplicaciones saml asociadas, e incluso aplicaciones on premises validadas con Azure Application Proxy.

Lo que haremos en realidad es situar una serie de Urls en la zona sitios de confianza de los navegadores y configurar los equipos para que entreguen el ticket Kerberos a esas Urls.

Para obtener esta funcionalidad, no es necesario contar con Azure AD P1 o P2 y cabe destacar que esta funcionalidad es compatible con el single sign on de Azure AD Join. La experiencia de usuario de SSO es más óptima y se consigue con escenarios híbridos al utilizar realmente la validación realizada en Active Directory con el ticket Kerberos.

Escenario actual

Sincronización de equipos

Hace ya tiempo que cuando configuro un AdConnect, no solo activo la sincronización de usuarios, sino que también activo la sincronización de equipos, teniendo luego estos equipos en Azure AD en un modo híbrido.

Con esta configuración tenemos los equipos unidos solamente a Active Directory local.

Sincronización de usuarios

Por supuesto los usuarios de Active Directory los tenemos sincronizados y configurados con su debido UPN en AD Local.

Configuración de Single Sign On en aplicaciones unidas a Azure AD

1. Validar que en AdConnect tenemos habilitado "Enable Single Sign On".

2. Validar dominio sincronizado

3. Comprobar la existencia de un equipo en AD con nombre AZUREADSSOACC

4. Crear nueva GPO que aplique a los puestos de trabajo y/o servidores de tu AD.

Aquí cabe destacar que por defecto, los navegadores no envían el ticket Kerberos a webs que no estén clasificadas en la zona. Por tanto, el equipo no enviará validación a la URL de Azure AD, a no ser que clasifiquemos la web como Intranet.

Tenemos que tener en cuenta también que usuarios no adminstradores de los equipos no pueden clasificar las webs en "sitios de confianza" o "Zona Intranet". Así que tenemos que hacerlo con una GPO.

4.1. Creamos una GPO y la asociamos a la OU donde guardéis los equipos.

4.2 Iremos a la ruta: Configuración de usuario -> Políticas -> Plantillas administrativas -> Componentes de Windows -> Internet Explorer -> Panel de control de internet -> Página de seguridad -- Selecciona Lista de asignación de sitio a zona y habilita la opción.

Añade los siguientes valores: https://autologon.microsoftazureadsso.com  Valor 1.

5. Habilitamos una segunda opción en la GPO.

Configuración de usuario -> Políticas -> Plantillas administrativas -> Componentes de Windows -> Internet Explorer -> Plantel de control de internet -> Página de seguridad -> Zona Intranet - Selecciona Permitir actualizaciones en la barra de estado a través de un script.

6. Vía GPO vamos a crear una entrada en el registro de los equipos.

Abrir herramienta de administración de políticas de grupo, editar la gpo e ir a la opción "Registro" en la ruta Configuración de usuario -> Preferencias -> Configuración de Windows -> Registro -> Nuevo -> Registry item

Añadir una entrada con path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon

Nombre de valor: https

Tipo de valor: REG_DWORD

Valor de dato: 00000001

Base: Hexadecimal

Resultado

Ahora solo tenéis que ir a la web https://myapps.microsoft.com/dominio.com* , https://outlook.office365.com/dominio.com*, https://portal.office.com?domain_hint=dominio.com*, https://dominio.sharepoint.com*,  https://portal.azure.com/dominio.com* o cualquier aplicación que envíe al registro de validación a login.microsoft.online.com 

*Sustituyendo dominio.com por vuestro dominio incluido en lo que conocéis como O365, pero que es Azure AD en realidad.

Solo tenéis ahora que ir con Edge a los links que he comentado y probar la validación. En próxima entrada os hablaré de como configurar esta experiencia con otros navegadores.

Renombrado de equipo en proyecto Workplace

 Hola, 

Os comparto un sencillo script utilizado para renombrar equipos en un proyecto de puesto de trabajo.

Este Script utiliza el número de serie para componer el nombre.  Además, teniendo en cuenta algunas condiciones se determina si el equipo es un laptop o un desktop.

Al inicio del script, veréis también que moderamos el resultado que nos devuelve el número de serie para evitar caracteres no permitidos en nombre de equipo en Active Directory.

El script también salta al UAC para evitar molestias.

$serial = Get-WmiObject win32_bios | select -expand serialnumber

$serial= $serial -replace '\.|/|:|\*|\?|"|\|\\', "&"

if(Get-WmiObject -Class win32_systemenclosure | Where-Object { $_.chassistypes -eq 9 -or $_.chassistypes -eq 10 -or $_.chassistypes -eq 14})

 {

    $newname = "LP-" + $serial.SubString($serial.length - 8)

 }

Else 

{

    $newname = "DP-" + $serial.SubString($serial.length - 8)

}

reg ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Rename-Computer $newname

reg ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f

shutdown -r -f -t 0