Okta rachète Stormpath

La nouvelle est tombée hier, la société Okta a réalisé l’acquisition de la société Stormpath. Pour ceux qui ne connaissent pas Strompath, la société propose une solution d’AUTHentification as a Service à destination des développeurs Web.

Attention, on ne parle pas ici d’une solution complète IDaaS comme  le propose déjà Microsoft, Centrify ou Okta, mais d’une brique à destination des développeurs permettant d’intégrer dans des services ou des applications web n’importe quel type d’authentification directement au niveau du code de l’application. Typiquement la solution Stormpath ne propose pas son propre annuaire Cloud (du moins pas du même niveau fonctionnel que Microsoft/Centrify/Okta) mais va permettre d’utiliser de nombreuses sources d’authentification différentes en intégrant au passage des mécanismes d’authentification forte ou de SSO:

Je m’étais intéressé à cette société quand elle avait fournie une Gateway permettant d’utiliser directement dans les applications SaaS un modèle d’authentification basé sur Active Directory ou LDAP:

Un modèle technique extrêmement intéressant axé sur les développeurs mais vraisemblablement un modèle trop réducteur pour résister aux points lourds de l’IDaaS qui commencent à proposer ce type d’API en standard dans leurs propres solutions. Voir par exemple chez Centrify:

Centrify Cloud API Guide: http://developer.centrify.com/site/global/documentation/api_guide/index.gsp
Centrify Cloud API Reference: http://developer.centrify.com/site/global/documentation/api_reference/index.gsp

Reste à savoir la raison de ce rachat de la part d’Okta. Pour moi la raison majeure n’est pas au niveau des APIs d’intégration (Okta a commencé à travailler sur ses propres APIs depuis quelques mois) mais au niveau de la technologie de gateway avec les éléments on-premises tels qu’un annuaire LDAP, Active Directory ou même un ADFS. En effet, sur cette brique majeure pour une entreprise d’une certaine taille, Okta était bien mal équipé… voulant imposer une vision à l’Américaine basée sur une approche pure Cloud Public à ses clients.

A noter, que la plupart des analystes ne sont pas d’accord avec moi et mettent en avant la partie API – voir par exemple: https://techcrunch.com/2017/03/06/okta-stormpath/ – ceci est normal puisque Stormpath est majoritairement connu pour cela… Mais pour moi ce n’est pas la raison principale, à moins que les équipes interne d’Okta aient vraiment fait du mauvais travail depuis quelques mois..

Il sera intéressant de suivre et comprendre comment les technologies Stormpath vont être intégrées à l’environnement Okta… Quelles briques technologiques vont être abandonnées… A suivre…

Directory as a Service (DIRaaS) : Découverte de JumpCloud [4/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [4/4]

Au travers de ce quatrième et dernier article, nous allons découvrir comment utiliser l’annuaire JumpCLoud comme un LDAP as a Service.

Activation et paramétrages de base du service « LDAP service »

Tout d’abord, il faut activer la fonction, pour ce, il faut se rendre dans la section SETTINGS et activer la fonction via le bouton ON/OFF :

Une fois que la fonction est activée, cela génère un « Organization ID », cet ID est utilisé pour identifier l’instance LDAP de l’organisation au niveau du service JumpCloud, une connexion vers cet ID sera renvoyé au niveau de la branche de notre organisation. En effet, chaque entité cliente de JumpCloud utilise le même annuaire LDAP mais avec des branches complètement indépendantes. Dans notre exemple, notre branche sera :

o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Il faut ensuite créer un compte LDAP qui servira de compte de service pour la connexion sur l’annuaire LDAP :

Et lui donner un mot de passe :

Bien sûr, il est possible d’activer la fonction « LDAP BINDING USER SERVICE ACCOUNT » pour n’importe lequel des utilisateurs, disons que dans notre exemple, nous considérons que la connexion doit être réalisée par un compte de service, comme le ferait une application cherchant des attributs dans le LDAP par exemple.

Test du service LDAP

Pour tester la connexion, nous allons utiliser une browser LDAP, il en existe de nombreux, mais nous utiliserons le freeware LDAP Browser 4.5 téléchargeable ici : http://www.ldapadministrator.com/download.htm

Il suffit d’installer le client LDAP sur une machine Windows et de lancer l’utilitaire puis de créer une nouvelle connexion :

La connexion doit avoir les caractéristiques suivantes :

Host (serveur LDAP) : ldap.jumpcloud.com

Port : 389

Base DN : ou=Users,o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Ici, 585322a6bc0b5b5c277062ee est notre organisation ID que l’on peut récupérer depuis la section SETTINGS de l’interface web de JumpCloud :

Il faut ensuite indiquer le compte de service avec lequel nous allons nous connecter sur l’annuaire LDAP et son mot de passe :

Dans notre exemple, le principal utilisé pour la connexion est:

uid=ldapservive,ou=Users,o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Nous avons ensuite accès à l’annuaire LDAP:

Avec par exemple, l’objet Sylvain Cortes :

Rajouter des groupes LDAP

Il est possible de rajouter des groupes LDAP dans l’annuaire en utilisant la fonction TAGS.

Définir un nom pour le TAG, qui sera aussi le nom du groupe LDAP et activer la fonction « Create LDAP groups for this tag » :

Puis rajouter des membres au groupe :

Il est alors possible de vérifier la présence du groupe et de ses membres depuis le browser LDAP :

Ce groupe LDAP pourra alors être utilisé depuis une application se basant sur des groupes LDAP pour fournir l’accès à certaines partie de l’application par exemple.

Les attributs utilisateurs : attention, rien à voir avec LDAP !

Dans l’interface de modification des comptes utilisateurs, il est possible de rajouter des attributs :

Attention, pour l’instant, ces attributs sont uniquement exploitables via l’API JumpCLoud et ne sont pas rajoutés dans le schéma LDAP. Il est prévu dans la roadmap de pouvoir rajouter des attributs LDAP et donc de rendre le schéma extensible, ce qui serait une fonction bien utile !

Voilà, cette série d’articles destinés à la découverte de l’offre JumpCloud est terminée. Je réaliserai vraisemblablement deux autres articles sur les fonctions avancées : les TAGS et la fonction de SSO via Fédération. En sachant que cette dernière fonction, pour moi, s’éloigne quelque peu de la fonction mise en avant qui est du DIRaaS et se rapproche plutôt des fonctions de IDaaS que l’on retrouve chez Microsoft, Okta et Centrify.

Si vous avez des questions sur le sujet ou si vous avez un projet allant dans ce sens, n’hésitez pas à me contacter par email ou via mon compte twitter : http://www.identitycosmos.com/sylvain-cortes_mvp

Directory as a Service (DIRaaS) : Découverte de JumpCloud [1/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [1/4]

Les différents fournisseurs de services d’identités hébergés dans le cloud se sont concentrés soit sur les fonctions de Identity as a Servive (IDaaS) ou de Cloud Access Security Broker (CASB), mais très peu ont tenté de proposer une véritable offre d’annuaire (DIRaaS) sous forme de SaaS.

Les seuls qui ont tenté la chose sont pour moi Microsoft (avec l’offre Azure Directory Services, nécessitant Azure Active Directory comme back-end), Amazon (AWS Directory Service, mais avec de nombreuses limitations techniques) et la société JumpCloud.

L’approche de JumpCloud est tout à fait innovante, car ils se positionnent comme des « pure player » fournisseur de DIRaaS et non pas comme fournisseur de IDaaS (bon, dans les faits, ils n’ont pas pu s’empêcher de mettre une brique de SSO basée sur SAML…). En effet l’idée est ici de fournir un « véritable » annuaire, dans le cloud qui est compatible par exemple avec LDAP ou RADIUS et demain pourquoi pas avec Kerberos.

L’idée de JumpCloud est donc de fournir un annuaire sous la forme d’un service. La difficulté de cet exercice réside dans le fait que les annuaires modernes ne sont pas simplement des annuaires LDAP – si l’on prend Active Directory par exemple, l’intégration avec Kerberos, la gestion des certificats ou dans une moindre mesure le lien Radius sont tout à fait remarquables. De plus, les annuaires modernes doivent pouvoir servir d’IdP pour les applications désirant consommer un service de fédération pour l’authentification des utilisateurs.

L’exercice de style n’est donc pas simple pour JumpCloud, voyons donc comment ils s’en sortent dans une série de quatre articles traitant de la découverte de cette offre en ligne. Si j’ai des retours positifs, j’aborderais ensuite dans une courte série de deux articles les fonctions avancées.

Pour se créer un compte d’évaluation, il faut se rendre sur cette page : https://jumpcloud.com/signup – une fois le formulaire rempli et le traditionnel lien de confirmation par email cliqué, le compte d’administration est prêt et l’on peut se connecter sur l’interface de gestion.

JumpCloud laisse à disposition une liste de « QuickStart Guide » pour bien prendre les choses en main – la liste de ces guides est accessible ici : https://support.jumpcloud.com/customer/portal/topics/947955-getting-started/articles

Le premier login administrateur sur le service JumpCloud

Voici le lien pour se connecter sur l’interface de gestion : https://console.jumpcloud.com/login

Il faut bien comprendre qu’il y a deux parties dans la mire de login, la partie « user » à gauche et la partie « administrator » à droite, il faut faire le bon choix car l’interface qui sera proposée derrière est différente en fonction de ce choix :

Une fois connecté à l’interface d’administration, un menu apparait sur la gauche permettant de sélectionner la zone d’administration, la partie de droite changera en fonction de ce choix.

  • USERS : Gestion des comptes utilisateurs, qu’ils soient créés directement dans l’annuaire manuellement ou qu’ils proviennent d’une synchronisation (depuis Active Directory par exemple)
  • SYSTEMS : Gestion des OS qui seront connectés à l’annuaire (Windows, Linux et MacOS) et qui pourront recevoir des règles de gestion depuis l’annuaire JumpCloud
  • TAGS : La gestion des TAGs permet de multiples choses, mais notamment l’association d’utilisateurs à des ressources ou à des objets (groupes)
  • APPLICATIONS : C’est la partie SSO vers des applications compatibles avec SAML (fédération d’identité)
  • COMMAND : Permet de programmer l’exécution de commandes sur les systèmes (OS) gérés dans l’annuaire
  • RADIUS : Utilisation d’un service serveur RADIUS as a Service

Création du premier utilisateur dans l’annuaire JumpCloud

La première connexion à l’interface d’administration permet de créer immédiatement des utilisateurs depuis la section USERS :

Ici nous allons choisir de créer un utilisateur qui aura des droits d’administration, il sera donc « Global Administrator », il pourra invoquer sudo sur les systèmes Linux et mais devra s’authentifier. De plus, l’utilisateur aura le droit de faire un Bind LDAP et de réaliser des recherches sur l’annuaire via LDAP. Enfin, nous lui définissons son mot de passe.

Un point important, ici, « Global Administrator » ne signifie pas que ce compte a des droits d’administration sur le service JumpCLoud en tant que tel, mais uniquement qu’il a des droits avancés sur les systèmes sur lesquels il pourra s’authentifier.

Après avoir cliqué sur le bouton « save user », nous avons notre premier utilisateur dans l’annuaire JumpCloud :

Quand on regarde les détails de sa fiche utilisateur, il est possible de constater que l’utilisateur à bien un « LDAP DISTINGUISHED NAME »:

Il est tout à fait possible de modifier ses attributs existants, par exemple son email :

Premier login utilisateur

Si maintenant on utilise cet utilisateur pour se connecter à l’annuaire JumpCloud en précisant qu’il s’agit d’un login utilisateur via l’URL suivante : https://console.jumpcloud.com/login

Nous constatons que l’utilisateur peut de lui-même éditer un certain nombre d’attributs ou de champs dans l’annuaire (attributs qui lui sont liés bien sur) :

Et qu’il a accès à des applications, la possibilité de rajouter des clés ainsi que la possibilité d’activer le MFA via Google Authenticator :

Distinction entre les comptes utilisateurs et les comptes administrateurs JumpCLoud

Attention, il faut bien comprendre qu’il y a trois types de comptes :

Type de compte Stockage Etendue d’administration
Administrateurs de l’instance JumpCloud Dans une base des administrateurs séparées de la base de l’annuaire en tant que tel Administrators

Administrators with Billing

Command runner

Command runner with Billing

Utilisateurs de l’entreprise Dans l’annuaire JumpCloud Aucune
Utilisateurs de l’entreprise avec des droits d’administration sur les systèmes Dans l’annuaire JumpCloud Certaines droits d’administration sur les systèmes eux-même

Base de comptes des Administrateurs JumpCloud:

La base de comptes des utilisateurs dans l’annuaire JumpCloud (représente les utilisateurs « end users » de l’entreprise :

Il est donc tout à fait possible d’avoir deux comptes avec le même login, un qui est administrateur JumpCloud et l’autre qui représente l’utilisateur au sens « end-user » avec deux mots de passe différents, lors de l’authentification en ligne, il faudra choisir sur quelle base de comptes (users ou administrators) se connecter :

Voilà ce premier article nous a permis de prendre en main la solution JumpCloud et de comprendre les bases de comptes utilisées. Dans le prochain article nous explorerons l’intégration des OS Windows et Linux au sein de cet annuaire.

Ubuntu: Mise à jour de la documentation intégration Kerberos/LDAP

ubuntu_kerberos_ldap

Comme vous le savez certainement, il est possible d’utiliser un annuaire LDAP comme conteneur des utilisateurs utilisés dans un royaume Kerberos. Sous Active Directory, cette « association » se fait naturellement, Active Directory proposant cette fonction de native et transparente pour les administrateurs.

Dans le monde Linux/Unix, cela est très différent, il faut expressément paramétrer le royaume Kerberos pour que celui-ci utilise un back-end LDAP pour stocker les informations utilisateurs, ensuite, en terme de protocole, on est sur du connu, Kerberos pour la partie authentification, LDAP pour la partie autorisations.

Franchement, quand on a compris le concept, ce n’est pas très compliqué, je dois avoué que l’avantage sur Unix/Linux, est une plus grande séparation des fonctions, donc une meilleure compréhension globale de l’architecture: Comme les choses ne sont pas faite automatiquement, et bien du coup, on comprend précisément les différences entre Kerberos et LDAP, cela rend vraisemblablement les choses plus simple à conceptualiser pour les débutants même si bien sur cela occasionne un paramétrage supplémentaire non nécessaire sous Active Directory.

Les concepts sont identiques sur l’ensemble des plateformes Linux mais chaque distribution a bien sur ses petites particularités. Ubuntu a mis jour dernièrement la documentation présentant cette intégration: dans ce scénario, les comptes utilisateurs sont donc créés dans LDAP, si la réplication LDAP est paramétrée, on a donc « l’équivalent » d’une réplication multi-maitres comme des contrôleurs de domaine Active Directory (enfin presque…) et un royaume Kerberos qui peut s’appuyer sur l’annuaire LDAP au lieu de s’appuyer sur une base de données Berkeley (ce qui est la configuration native d’un royaume Kerberos) pour stocker les objets utilisateurs.

La documentation pour Ubuntu, en Français est accessible [ ICI ]

Pour une référence plus générique et globale, vous pouvez aussi consulter la documentation MIT Kerberos [ ICI ]

 

 

XACML is dead or not ?

xacml.plain.logo

 

Depuis maintenant plusieurs années, je m’intéresse à l’évolution du « standard » XACML, en me posant bcp de questions… En effet, d’un point de vue technologique, je pense qu’il s’agit d’une excellente manière de gérer les rôles applicatifs au sein des grandes entreprise. Pour faire simple, XACML est plutôt un langage structuré (basé sur XML) qui permet de décrire des rôles et surtout des politique de contrôle d’accès – ces politiques peuvent être simples, très complexes et peuvent se baser sur des éléments dynamiques ou contextuels: par exemple mes « droits » définis dans le code XACML peuvent s’adapter en fonction de l’adresse IP que j’ai, ce qui permettrait d’adapter mes droits si je suis sur le LAN ou depuis un VPN, etc. Encore une fois, d’un point de vue technique, je pense que c’est le top, c’est un peu monolithiques, mais au final on peut gérer des cas très complexes – le problème est que l’adoption (en tout cas en France) de ce standard est très faible – il y a peu de changements depuis 4 ans, quelques POC, mais pas de mise en production – en effet, le problème majeure est qu’il faut écrire une partie des applications « in house » pour bénéficier de XACML, il y a déjà peu d’entreprises qui font du profiling applicatif dans un annuaire LDAP, alors XACML…on imagine… Je suis retombé sur un article d’un consultant Forester qui date maintenant de 3 ans, voir: http://blogs.forrester.com/andras_cser/13-05-07-xacml_is_dead – ce qui est amusant c’est que l’on pourrait avoir écrit l’article hier 😉 Les commentaires sont extrêmement intéressants également, un peu partisans, mais intéressants !

Donc que conseiller ? XACML or not XACML ? et bien je ne sais pas… Je pense que je conseillerais à une entreprise (à partir de 50 000 users) d’au moins faire un POC de la technologie, et de comparer avec le mode de profiling et de contrôle d’accès actuel. De plus, je pense que nous ne verrons jamais des plug-in applicatifs « sur étagère » (ce qui est bien dommage…) genre un plug-in XACML pour SharePoint, pour SAP, pour Apache, etc… ce qui sous-entend que chaque entreprise devra écrire et maintenir le module XACML pour chaque application importante.

Quels liens pour aller plus loin:

https://en.wikipedia.org/wiki/XACML

https://www.axiomatics.com/ (pour moi le seul fournisseur XACML qui respectent vraiment les standards OASIS avec Oracle)

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

 

Tutorial: how to store or migrate UNIX NIS maps in Active Directory using the Centrify NIS Gateway

I received a lot, I mean a lot, of requests after I had published my 3 last posts about the storage of NIS maps in Active Directory [http://bit.ly/1S4gKUGhttp://bit.ly/1qvvyzrhttp://bit.ly/1q8iAHi ] – The main problem was my posts are in French 😉 and a lot of people tried to use Google Translate to get it, but it wasn’t perfect. So, from the popular demand, I decided to translate it in English. English is not my native language, so sorry in advance if you will find some ‘bugs’ in the text.

As I explained in one of my last post (sorry again in French !), Microsoft announced it will not implement some Unix Services in Windows 2016 and Active Directory 2016 anymore, including NIS Services.

Through my different projects, I had meet a lot of organizations which are using mixt environment with Windows and Unix boxes and I can say the NIS usage is even nowadays very widespread. For sure, it is very bad to use NIS authentication and NIS authorizations, it is really better to use Kerberos ad LDAP instead. I will not go in the details now, but it is true that NIS is not something secured, however, the fact to totally eliminate the NIS Services is impossible for a lot of organizations. These organizations have a « IT history », from years, and a lot of very important information still remain in the NIS maps (automount, etc.)

So, the goal is to use Kerberos/LDAP for authentication/authorization services and a NIS Gateway service which expose to NIS client the maps NIS which are stored in Active Directory. Using this way, we get the best of the two worlds, we can secure the authentication with Kerberos and the organization is able to continue to use the NIS maps for the legacy needs.


In this tutorial, we will use the NIS Gateway provided by Centrify and get a magic trick to improve security without abandon the NIS history.

Inn this tutorial, we will use a Fedora 23 workstation as a NIS Gateway and Fedora 23 as a NIS client, in my example the Active Directory is a Windows 2012R2 one, but it will work with various flavors of Linux/Unix and with different versions of Active Directory.

A/ First step: Centrify packages installation on the future NIS Server (=NIS Gateway)

First, we need to set our NIS Gateway with a hostname and with a IP which permit to the NIS Gateway to communicate with the Active Directory world. Here, we consider that the basic settings regarding the Centrify Zones are already done (just refer to the Centrify Quick Start Guide to do it).

1/ Hostname settings


In our example, the hostname of the NIS Gateway will be: nisserver01.demo.local

2/ SSH checking

We will check that the SSH server service is present on the Linux box, we will need it to transfer the packages for the Centrify agent and the packages for the Centrify NIS Gateway on the NIS Server.


If the SSH server is not installed, type the following command to install the SSH server packages:


When the SSH packages are installed, you need to start the SSH service


3/ Centrify packages transfer to the machine

We will use WinSCP to transfer the Centrify agent (Centrify Server Suite 2016) on the NIS server (/tmp directory for example) – for a Fedora23 OS, the name of the package is centrify-suite-2016-rhel4-i386.tgz


4/ Centrify agent installation

Go the the /tmp directory and check you have the agent package.


Unzip the package:


Instal the agent, using the install.sh script:


The install.sh script will check everything to be sure your system is able to get it – if you don’t have any ‘failed » result, you will be able to install the agent – if you get some ‘warning’ result, it is not really important (we are doing a POC !)


Choose the Enterprise or the Standard version, it doesn’t matter for the NIS Gateway itself, so let’ choose Enterprise [E] in our example:


Choose the run adcheck again (just to be sure…) et provide the needed information linked to Active Directory during the installation process – In our example, we will join a zone named arizona, so our NIS server will provide « NIS service » for this zone – and choose to not reboot at the end of the installation:


As soon the information will be provided, the install process will start, but just before the installation process will ask you to verify your different values.


The installation process is starting – after the adcheck final check, just validate the agent installation process:



At the end of the process, the Centrify agent installation proceeds:


Now, we will install the package which will update the SSH Server packages with the Centrify packages – this is not 100% mandatory, but it will provide a better integration with Kerberos authentication, so let’s do it:


Now, we will install the Centrify NIS Gateway package:


At the end, just reboot the system, again this is not 100% mandatory, but let’s do it easier and reboot the system.

At this stage the first big step is over. Let’s see now how to set Centrify NIS Gateway.

B/ Second step: Centrify NIS Gateway settings

1/ Active Directory integration of the NIS Gateway Linux box

We will integrate the NIS Server in the zone named arizona. We consider here that you already performed the basic step of the Centrify installation procedure (refer to the Centrify Quick Start guide for details) and we consider you already created some Centrify zones in Active Directory.

First, let’s connect to the NIS Server and execute the following command to perform the Active Directory join to the arizona zone:


In our example, the domain is named demo.local, the Centrify zone is named arizona and the Active Directory service account used to perform the Active Directory join is named centrify. And the password for the service account is …no, for sure, just kidding ;-)) – but the join process will ask you the password for the Active Directory service account.


After few seconds, the following window will appear, saying everything is ok:


It is not mandatory to reboot the server itself, but to make it easier, let’s reboot the server:


2/ Let’s check some important things

Now let’s set some accurate parameters of the Centrify NIS Gateway. We will start to start the management tool Centrify Access Manager, we will find a new machine account in the zone names arizona, it is nisserver01:


This is another view with the list of the machines in the Centrify zone. We will use a other machine from this zone to be NIS client (ypbind) of our NIS Gateway. For sure, the NIS Gateway as a NIS server only for the machines which are in the same zone.


As we didn’t specify a specific container during the Active Directory join of the NIS Gateway, the computer object which represents the NIS server is stored by the containers Computers in Active Directory or any default container if you changed your Active Directory configuration:


Because we will apply some specific GPOs on the computer object which represents the NIS Gateway, we will create a new organization unit (OU) and we will move the computer object in it- in our example, the OU is named NIS_Gateway:


Now, we will start our NIS Gateway computer. When the computer will be started, it would be possible the use any AD account with a UNIX profile in the Centrify zone to log on it, but we will log as root to make it more convenient for the future manipulations.

As soon you are logged on the system, just type the adinfo command, you will obtain information about the state of the adclient daemon which represents more or less a Active Directory client for UNIX/Linux:


The most important thing is to have the value ‘connected’ for the attribute ‘CentrifyDC mode’, this means the system is truly connected to Active Directory and communicate with it. At this stage, our Linux server is integrated in Active Directory and it is totally secured, thanks to Centrify technology.

3/ Apply specific settings on the Centrify NIS Gateway

Let’s set some settings to set the correct behavior of Centrify NIS Gateway (adnisd).

First, we will use the Centrify extension for the GPMC to create some specific GPOs to set the NIS Gateway, nisserver01. Centrify provides some ADMX files if you just want to use the classic GPMC provided by Microsoft, so you can import the administration model in the GPMC. Or you can install some Centrify GPMC snap-in to create the UNIX/Linux GPOS. It is up to you, but you need to do one or the other.

Here we will use the ADMX files method, and e consider we already import the different ADMX files in the GPMC. Open the GPMC and go the node « computer configuration / Strategy / Administration model / Centrify Settings / DirectControl Settings / NIS Daemon Settings:


Edit the ‘Specify allowed client machines for NIS daemon‘ property and set the value to 0/0:


We need to do so, because by default, the NIS Gateway only accept NIS request from itself (I will not go in the details, but in some specific secured configurations where you need to deploy the NIS Gateway packages on all the UNIX systems, this « by default » behavior is useful). So we need to define the is of the IP addresses which are authorized to request the NIS service, if you set the value to 0/0, the NIS server will accept all the request from all the client.

Let’s edit also the ‘Specify NIS daemon update interval‘ property and set the value to 60.


This property will allow us to set the synchronization time between Active Directory and the NIS Gateway. Because of performance reasons, the NIS Gateway maintains a local cache of the values from Active Directory, so in our example, the values will be replicate every minute. In a production environment, a value between 16 and 30 minutes seems a good choice.

Just validate the GPO and close the GPMC. If you want to update the NIS Server with these new settings, it is just matter to execute the adgpupdate command on the NIS Server, this command will refresh the GPOs settings from Active Directory. You can also wait for the next GPO application process (the time period will depend of your Active Directory settings):


It is possible to check which GPO is applied or not by executing the adgpresult command on the system, here, we will see the settings we just created in the new GPO we created:


C/ Third step: Verify some elements on the Centrify NIS Gateway settings

As you may know, to have a consistent NIS Server on a system, we need to have RPC services up and running. If you don’t know so much about NIS, I recommend to read this book which is for me a sort of « NIS bible » [ special thanks to Randip M to let me know about this book. 😉 ]

I will not go in the very details, but globally the RPC server service will receive the requests from the NIS/RPC client from the network, so the RPC server service will decide to use a certain port number, using the port mapper, then the communication between the client and the server will use this specific RPC port for the rest of session. So to have a NIS server running in the right shape we need to have a RPC server running in the right shape.

To verify if everything is ok for the RPC server, execute the following command: rpcinfo –p localhost


Here we can see we have six port mappers waiting for a RPC connection, so everything is ok.

We will now check if the Centrify NIS Gateway service (adnisd) is up and running by executing the following command: systemctl status adnisd –l


If the adnisd service is not running, execute the following command to start it: systemctl start adnisd –l

When we execute the command systemctl status adnisd –l to check the status of the service, we have a message saying that we don’t have any NIS map stored in Active Directory, at this stage it is totally normal, we will publish NIS maps in Active Directory latter.

D/ Fourth step: Check the configuration of the NIS client

1/ some thoughts about what we are doing here…

At the Linux client level, it is very important to understand that we have two different components:

– The Centrify DirectControl agent which provides the ability of the system to be fully integrated in Active Directory and provides the Kerberos and LDAP layers for authentication and authorization against Active Directory – Even if we have a NIS client on system to use NIS maps, the authentication is not managed by NIS but by Kerberos

– The NIS client of the Linux system – this is not a component provided by Centrify agent installation, here we are using a generic client, which could be slightly different from different Linux/UNIX forks – never mind, the generic NIS client will use « classic » NIS exchange with the Centrify NIS Gateway, so it will work

The good thing with this scenario, is we will get all the advantage provided by the Centrify agent but we will be able to use legacy NIS maps. As the NIS gateway server itself is using a Centrify agent, all the communication between the NIS gateway and Active Directory is secured. Another big advantage is the fact that we will not have any more a dependency with one single NIS Master – in this scenario, the « NIS master role » is technically provided by the different AD domain controllers, as the AD domain controllers are using multi-master replication, we don’t have any single point of failure there – The NIS gateway will act as a NIS slave and will cache the information from AD on his own system, and we reply to the NIS requests from the network.

It is existing other scenarios, where the NIS authentication (ok, I don’t like to use the expression « NIS authentication » because NIS is NOT an authentication protocol, but I make the things simple here by comparing with Kerberos…) will be provided by NIS even if the NIS maps are stored in Active Directory – but in this scenario we will need to store in Active Directory a hashed version of the user passwords compatible with NIS, we will not review this particular scenario there because it is not really used anymore and above all because it is not really secured (I will even say it is not secured at all…).

2/ Apply some settings at the NIS client level

Perform a connection, using root, to the NIS client, in our example, the NIS client hostname is : fedora23.

We will first check if the ypbind service (the NIS client) is up and running, so let’s execute the following command: systemctl status ypbind –l

If you get something like this :


It means the service is not started, and it means the ypbind packages are even not installed at all.

To check is the package are installed or not, let’s try to start the service using this command: systemctl start ypbind –l

The following message will confirm that the ypbind packages are not installed at all:


To install the NIS client packages, execute the following command: dnf -y install ypbind rpcbind

If rpcbind was already installed, you will get this message, it is not a big deal, just ignore it :


In all the situations, you may obtain something like that at the end of the packages installation:


After packages installation, I advise you to restart the system, it is not purely technically a requirement, but I was used to be a Microsoft Guy 😉

Never mind if you just installed the NIS client packages or if you were using it during years before this tuto, we will now stop the ypbind service on the client to apply some settings at the NIS client level: systemctl status ypbind –l

To be sure we will not have bad behavior because of previous settings/usage, we will delete all the files which are in the var/yp/binding directory: rm -rf /var/yp/binding/*

Now, we will define the NIS domain name at the client level – remember, by default, the NIS domain name is equal to the Centrify zone name where our NIS Gateway is acting, in our example, the zone name is arizona. So let’s execute the command: domainname arizona


Then, we will edit the /etc/yp.conf file to set the NIS domain name and the NIS Gateway hostname – in our example, we need to add the value: domain arizona server nisserver01

Example, with the nano editor:


If you are using nano, after editing the value, let’s use Ctrl+O & Ctrl+X

Now, let’s start the ypbind service: systemctl start ypbind –l

You can check the service status using this command : systemctl status ypbind –l


Note: if the NIS client is not able to contact the NIS server, so the NIS client service will not start. If you get an error when you try to start the NIS client service, the first thing to do is to disable the firewall service on the NIS server (use the following command to stop the firewall on a fedora system: systemctl stop firewalld –l )

At this stage, we have a NIS server and a NIS client which are able to communicate each other, let’s publish some NIS maps in Active Directory now !

E/ Fifth step: Publish some NIS maps in Active DIrectory

In this tutorial, we will use the Centrify graphical tool « Centrify Access Manager » to publish some information in the NIS maps, but you can do it using different ways (LDP command for example).

Start the Centrify Access Manager tool, and go the Centrify zone (arizona in our example) – Then go to ‘Unix Data’, then ‘NIS maps’ node. Right-click on the node and choose ‘New / Generic Map’:


In our example, we will create a Generic Map, i.e. a map used to store text information with no direct relation with something used by the Linux system itself. For sure, you create some ‘classic’ NIS maps like Automount or Netgroup, but we will not cover the usage of these NIS maps in this article.

In this example, the NIS maps name is test and we have a key test01 with the value test0101:


From the NIS client, execute the following command: ypcat test – you may get the values from the NIS map test :


Here we go, it is working fine !

With the ypwhich command you will be able to confirm the NIS server name used by the NIS client (so in our example, it is the NIS Gateway hostname:


F/ One step beyond…

1/ Generated NIS maps

Let’s now explore, some advance details. To get the list of NIS maps from a NIS master server you need to execute the following command ypwhich –m


Here you can note two important things:

(1) from a NIS client, the NIS gateway is considered as NIS master server

(2) we created only one NIS map (test) in d’Active Directory but the NIS client is able the « see » four other NIS maps : passwd.byuid / passwd.byname / group.byname / group.bygid – These four maps are what we call ‘derived maps’, there are implicited generated from Active Directory data – In fact, at the system level (NIS client side), the NIS client needs to have a visibility of these four maps, so you don’t need to create it, the Centrify NIS gateway will create it and update it for you. So the passwd.byuid and passwd.byname maps will be automatically generated from the UNIX user profiles from the arizona zone, and the group.byname and group.bygid maps will be automatically generated from the UNIX group profiles from the arizona zone. Remember, behind the scene, the UNIX user profiles and the UNIX group profiles are linked with ‘real’ Active Directory user and group objects.

If you are using the command ypwhich –x you will be able to see the correspondence between NIS maps aliases and the real technical name of such NIS maps.


If you are using the command ypcat passwd you will be able to see the content of the generated map passwd.byname which is the list of the UNIX user profiles from the zone arizona :


To fully understand this feature, you can open the graphical tool Centrify Access Manager and check the list of UNIX user profiles from the arizona zone, you will exactly the same list :


2/ NIS maps objects in Active Directory

We can check how the NIS maps objects are stored in Active Directory – let’s use Microsoft Active Directory Users and Computers tool (ADUC) or a basic LDAP client to do so.

If you go to the zones containers, you will be able to see all the Centrify zones you created (not cover by this article) – select the arizona zone, and the NisMaps container, you will list the NIS map we created, means the test NIS map.

Under the test container (our NIS map), you will see the entry we create named test01:


If you do right-click on the test01 object and choose ‘Properties’ (with ADUC, Attribut Editor), you will see the different values from the different attributes used by Centrify to store the information:


If you look at three specific attributes, we will review the values we put in the system with the Centrify Access Manager tool for our test map – as a reminder:


These are the three attributes:

KEY: (description)


VALUE: (adminDescription)


COMMENTS: (wWWHomePage)


For sure, you will be able to use Active Directory ACLs Active Directory to provide access and delegation for such NIS map or even some specific rights on a specific value: this is very useful to define the NIS administrators AD group which will be able to create or update NIS map values in the future:


The main difference for the UNIX administrator will be the interface. As now the NIS maps are stored in Active Directory, they will use a LDAP Browser, the Centrify graphical tool or some LDAP script to maintain the NIS maps contain.

At the end, the ideal situation will be to use a IAM tool such MIM for example to manage the NIS maps lifecycle with delegation, workflow, approval and activity logs !

We did it !

Now, this tutorial is finished. Don’t hesitate to add some comments or contact me if you have any questions. Let’s discuss on twitter (@sylvaincortes) or by email if you have a NIS migration project, we can help you 😉

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [2/3]

 

Lors de notre post précédent nous avons vu comment installer l’agent Centrify (adclient) et le package de la Centrify NIS Gateway (adnisd) sur le serveur qui publiera les maps NIS stockées dans Active Directory.

Nous allons maintenant voir comment activer l’agent Centrify sur la NIS Gateway, comment réaliser quelques GPOs depuis Active Directory pour paramétrer la NIS Gateway et finir par des vérifications locales à faire sur la NIS Gateway.

Tout d’abord nous allons intégrer le futur serveur NIS dans Active Directory et le faire rejoindre une zone Centrify. Nous considérerons ici que la partie basique d’une installation Centrify a déjà été réalisée, et que des zones ont été créées. Je vous laisse jeter un œil sur la documentation (notamment le Quick Start Guide) sur ces étapes extrêmement basiques. Dans notre exemple, la zone que nous allons rejoindre se nomme arizona.

Tout d’abord, se connecter en root sur le systèmes (sur le futur serveur NIS donc) et exécuter cette commande pour rejoindre Active Directory et la zone nommée arizona:

capture20160405142931118

dans notre exemple: le domaine AD se nomme demo.local, la zone Centrify à rejoindre se nomme arizona et le compte de service (Active Directory) ayant le droit de joindre une machine au domaine se nomme centrify – ensuite, le mot de passe AD pour le compte utilisateur/administrateur centrify sera demandé:

capture20160405142947712

Après quelques secondes, la fenêtre suivante apparaitra, vous confirmant que l’opération s’est bien déroulée:

capture20160405143023882

Nous pourrions nous amuser à ne redémarrer que certains services, mais allons redémarrer le serveur NIS, ce sera plus simple:

capture20160405143109675

Maintenant, laissons le système Linux de côté quelques instant et utilisons quelques outils de gestion proposés par Centrify pour affiner notre configuration.

Lancer l’outil Centrify Access Manager, nous constatons qu’une nouvelle machine a rejoint la zone arizona, il s’agit de nisserver01, notre futur serveur NIS:

capture20160405143154356

Une autre vue, avec la liste des machines qui sont dans la zone Centrify, pour information, la machine fedora17 nous servira de client NIS (ypbind) pour les tests, pour que cela fonctionne il faut bien sur que la NIS Gateway et le client NIS soient dans la même zone Centrify:

capture20160405143220837

Comme nous n’avons pas spécifier de conteneur Active Directory spécifique lors de la jointure au domaine de la machine Linux (notre futur serveur NIS), l’objet Computer le représentant dans Active Directory s’est créé dans le conteneur par défaut, si vous n’avez pas fait de modification au niveau d’Active Directory, vous retrouverez alors l’objet Computer dans le conteneur nommé Computers:

capture20160405143259227

Pour la suite des tests, et notamment pour l’application de certaines GPOs sur le serveur NIS lui-même, nous allons créer une Unité d’Organisation (UO) dans laquelle nous allons déplacer l’objet AD représentant le compte ordinateur du serveur NIS, dans notre exemple, l’UO se nomme NIS_Gateway:

capture20160405143414531

Nous allons maintenant démarrer notre serveur NIS. Une fois démarré nous pourrions maintenant utiliser n’importe quel compte AD ayant un profil UNIX dans la zone et ayant les droits de login pour nous authentifier sur le système – pour plus de souplesse, nous continuerons d’utiliser le compte root pour les différentes manipulations.

Si nous nous connectons sur le système, et que nous tapons la commande adinfo, nous devons obtenir des informations sur l’état du service adclient qui représente le client AD du système Linux:

capture20160405143515949

Le plus important est que l’attribut ‘CentrifyDC mode’ est bien la valeur ‘connected’, cela signifie que le système est bien connecté à Active Directory. A ce stade nous avons un serveur Linux intégré dans Active Directory, dans une zone Centrify et qui est fonctionnel d’un point de vue système et totalement sécurisé par l’agent Centrify.

Nous allons maintenant voir certains éléments spécifiques à la partie NIS Gateway (adnisd).

Tout d’abord nous allons utiliser l’outil d’administration Centrify pour créer des GPOs spécifiques aux serveurs NIS qui s’appliqueront à notre serveur nisserver01. Centrify propose soit d’intégrer directement des fichiers ADMX au niveau de la GPMC soit d’installer un snap-in présentant les GPOs spécifiques aux environnements Unix/Linux et MacOS toujours au niveau de cette même GPMC. Il faut bien sur au préalable avoir fait une de ces deux manipulations.

Ouvrir la GPMC, se rendre sur le noeud Configuration ordinateur / Stratégies / Modèles d’administration / Centrify Settings / DirectControl Settings / NIS Daemon Settings:

capture20160405143959120

Editer la propriété ‘Specify allowed client machines for NIS daemon’ et renseigner la valeur 0/0:

capture20160405144020742

En effet, par défaut, le démon adnisd n’accepte que les requêtes locales, c’est à dire, les requêtes NIS émises depuis le serveur NIS lui-même (je ne rentrerai pas dans les détails, mais cette configuration est utilisée dans des cadres précis de sécurité), il faut donc spécifier les adresses IP qui auront le droit de lancer des requêtes NIS vers notre NIS Gateway, si l’on renseigne la valeur 0/0, toutes les requêtes NIS seront acceptées.

Editer également la propriétés ‘Specify NIS daemon update interval’ et renseigner la valeur 60:

capture20160405144101425

Cette valeur (par défaut sur 30 minutes) permet de spécifier l’intervalle de rafraichissement des données entre Active Directory et le cache local de la NIS Gateway. En effet, pour des raisons de performance, les informations des maps NIS stockées dans Active Directory sont mises en cache au niveau de la NIS Gateway (comportement par défaut), nous mettons ici la valeur sur 60 secondes afin de ne pas trop attendre entre les modifications faites dans Active Directory et leur synchronisation sur la NIS Gateway. En production, une valeur entre 15 et 30 minutes est tout à fait acceptable.

Valider la GPO, et refermer la console de gestion des GPOs Centrify.

Pour mettre à jour notre futur serveur NIS avec ces nouvelles valeurs de configuration (celles de la GPO), il faut se connecter sur le serveur NIS et exécuter la commande adgpupdate afin de forcer le rafraichissement de la GPO sur le système Linux, sinon attendre la prochaine application des GPOs:

capture20160405200401273

Pour visualiser les GPOs qui sont bien appliquées sur le système, exécuter la commande adgpresult, nous retrouvons bien les paramètres appliqués de notre GPO créée précédemment:

capture20160405200555997

Nous allons maintenant vérifier quelques éléments au niveau de notre serveur NIS Gateway.

Tout d’abord pour qu’un service NIS s’exécute convenablement sur un système, il faut que les services RPC soient opérationnels. je ne rentrerais pas les détails, mais globalement le service RPC du serveur va recevoir la requête, décider d’un numéro de port RPC pour la connexion cliente du client NIS et donc permettre la communication entre le client et le serveur. Il faut donc que RPC fonctionne correctement sur le serveur NIS, pour vérifier cela, exécuter la commande  rpcinfo –p localhost

capture20160405144954620

Nous voyons ici 6 portmapper en attente de demande d’échange RPC, tout va bien.

Nous allons maintenant exécuter la commande systemctl status adnisd –l afin de vérifier que le service adnisd est bien démarré et fonctionnel:

capture20160405202502019

Si jamais le service n’est pas démarré, exécuter la commande systemctl start adnisd –l pour le démarrer.

Le résultat de la commande systemctl status adnisd –l nous indique à la fin qu’il n’y aucune NIS map dans Active Directory, à ce stade, c’est tout à fait normal.

Dans le prochain et dernier article de cette série consacrée à l’utilisation d’Active Directory pour le stockage des maps NIS à destination des clients UNIX ou Linux, nous verrons comment publier quelques maps NIS dans Active Directory, comment paramétrer des clients NIS (ypbind) pour interroger ces même maps NIS et comment réaliser quelques tests supplémentaires.

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [1/3]

 

Comme indiqué dans un de mes derniers posts, Microsoft a annoncé la suppression de certains services Unix majeurs au sein de Windows 2016 et donc d’Active Directory 2016.

Au travers de mes projets, je rencontre de nombreuses sociétés qui utilisent des environnements mixtes Microsoft/Unix, et il est clair que les services NIS ont la vue dure… Bien sur, il ne faut pas gérer les authentifications et les autorisations via NIS, au profit d’utiliser Kerberos et LDAP. Je ne vais pas rentrer dans les détails ici, mais c’est comme dans Ghosbusters, utiliser les services NIS, c’est “mal”… Néanmoins, pour de nombreuses organisations, l’élimination totale des services NIS est un véritable challenge, car ces même organisations gère depuis des dizaines d’années des informations très importantes pour leur production dans ces fameuses map NIS (automount ou autre).

L’idée est donc généralement d’utiliser Kerberos/LDAP pour utiliser les services d’authentification et d’autorisation d’Active Directory et un service NIS “gateway” qui permettra d’accéder à Active Directory de façon sécurisée pour proposer le service NIS server depuis cette gateway. De cette façon, on obtient le meilleur des deux: on sécurise les services d’authentification par Kerberos et on permet à l’organisation de continuer à utiliser NIS pour exposer des maps “legacy”.

capture20160403202213508

Nous allons donc utiliser les services de NIS gateway proposés par la solution Centrify pour réaliser cette prouesse technologique et fonctionnelle Smile

Pour ce, nous allons paramétrer une workstation Fedora 23 en tant que passerelle NIS vers Active Directory.

Tout d’abord, il faut bien paramétrer votre Fedora pour vous assurer de lui donner un nom hostname qui corresponde à votre besoin et lui donner un paramétrage IP qui permette à cette passerelle NIS de communiquer avec Active Directory. Nous considérons ici, que les paramétrage basiques d’installation et de paramétrage de Zones Centrify ont déjà été effectués.

1/ Paramétrage du hostname

capture20160403204153493

Dans notre exemple, le hostname du futur serveur NIS sera: nisserver01.demo.local

2/ Vérification du service SSH

Nous allons vérifier que le service SSH Server est présent sur la machine, ceci afin de nous permettre de transférer les package de l’agent Centrify et de la NIS Gateway sur le futur serveur NIS

capture20160403204414276

Si le serveur SSH n’est pas installé, renseigner la commande suivante pour installer les packages:

capture20160403204724703

Une fois que les packages SSH sont installés, démarrer le service SSH serveur

capture20160403204915783

3/ Transfert des packages sur la machine

Via WinSCP, nous allons transférer l’agent Centrify de la version Centrify Server Suite 2016 sur la machine (dans le répertoire/tmp) pour une fedora 23, le nom du package est centrify-suite-2016-rhel4-i386.tgz

capture20160403205117288

4/ Installation de l’agent Centrify

Vérifier que l’agent est bien dans le répertoire /tmp:

capture20160403210045886

Décompresser le package de l’agent:

capture20160403210228837

Lancer l’installation de l’agent:

capture20160403210414251

Le script d’installation va lancer une vérification pour voir si la plateforme sera compatible avec l’installation de l’agent – si aucun test ne sort en “failed”, l’installation sera possible, les “warning” ne sont pas rédhibitoires pour l’installation:

capture20160403210626167

Choisir d’installer la version Enterprise ou Standard, en ce qui nous concerne pour le service NIS, cela n’a aucune importance – dans notre exemple, nous choisissons Enterprise [E]:

capture20160403210930120

Choisir de lancer adcheck à nouveau (pour être sur…) et renseigner les informations liées à Active Directory que demandera le processus d’installation – dans notre exemple, nous allons rejoindre une zone Centrify nommée arizona, notre futur serveur NIS fournira donc des services NIS pour cette zone Centrify – choisir de ne pas redémarrer à la fin de l’installation:

capture20160403211412414

Une fois les informations fournies, le processus d’installation vous demande de valider une dernière fois les informations fournies avant installation et paramétrage de l’agent:

capture20160403211646995

Le processus d’installation commence – après le processus adcheck, valider l’installation de l’agent:

capture20160403211958028

capture20160403212104744

L’installation se termine avec l’installation des agents Centrify:

capture20160403212219329

Nous allons maintenant installer le package permettant de mettre à jour le serveur SSH livré avec l’OS par la version serveur SSH Centrify qui permet une meilleure intégration au niveau de l’authentification Kerberos intégrée:

capture20160403213437402

Nous allons maintenant installer le package du serveur Centrify NIS Gateway:

capture20160403213822508

Nous allons maintenant pouvoir redémarrer le système !

Lors du prochain article, nous verrons ensemble le paramétrage de l’agent Centrify, le paramétrage du service NIS Gateway et nous publierons quelques maps NIS dans Active Directory afin de les rendre accessibles pour des clients NIS Unix/Linux sur notre réseau.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify.

Lors de l’article précédent, nous avons préparé l’environnement, maintenant tout est prêt et le package DMG est sur le bureau d’un compte local MacOS X avec des pouvoirs d’administrateur :

clip_image002

La dernière des choses à vérifier est que le MacOS X n’est pas relié à Active Directory avec le plug-in Active Directory natif de MacOS X, ceci est très important. Pour vérifier, choisir l’option Utilisateurs & Groupes / Users & Groups dans les préférences systèmes :

clip_image004

Ici, il n’y pas de domaine joint, c’est donc parfait :

clip_image006

Passons maintenant au choses sérieuses…

[1] Vérification de l’environnement grâce à ADCheck

Le package DMG contient un outil de vérification de l’environnement avant installation de l’agent, il faut donc ouvrir l’image DMG:

clip_image008

Et choisir l’icône AD Check au lancement d’AD Check, l’assistant vous demande le nom de domaine du domaine que vous souhaitez rejoindre afin de faire les vérification, dans mon exemple, le nom de domaine est demo.local:

clip_image010

Puis cliquer sur le bouton bleu AD Check

clip_image012

clip_image014

Pour que la future installation se déroule sans encombre, il faut que vous n’ayez aucun "Failed" dans la liste des résultats aux tests – par exemple, ici, l’assistant AD Check m’indique que un des serveurs DNS que j’utilise sur ma machine ne gère pas le nom de domaine demo.local – nous allons donc l’enlever de la configuration DNS et refaire les test AD Check:

clip_image016

Ça y est, tout va bien !

[2] – Installation de l’agent et rejoindre le domaine AD

Lancer le package pour l’installation de l’agent Centrify:

clip_image018

Choisir "Continue":

clip_image020

Puis à nouveau sur "Continue":

clip_image022

Puis, après avoir lu le Software License Agreement, à nouveau sur "Continue":

clip_image024

Puis sur "Agree":

clip_image026

Puis sur "Install":

clip_image028

Indiquer le mot de passe de l’administrateur local (ici, le mot de passe pour Florent) et appuyer sur "Install Software":

clip_image030

Le processus d’installation de l’agent se poursuit alors :

clip_image032

A la fin du processus, choisir l’option "Launch centrify Join Assistant" (sélectionnée par défaut) et choisir "Continue":

clip_image034

La fenêtre de l’installateur indique que tout s’est bien déroulé :

clip_image036

Et une nouvelle fenêtre apparait pour lancer l’assistant AD JOIN, cliquer sur "Continue":

clip_image038

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image040

Indiquer alors le nom de domaine du domaine AD à rejoindre (ici demo.local), un compte administrateur AD qui a le droit d’écrire dans AD (à minima dans les UOs que vous avez créé dans l’article précèdent) ainsi que le mot de passe de ce compte d’administration AD, puis cliquer sur "Continue":

clip_image042

Indiquer les options pour rejoindre le domaine, vous pouvez garder toutes les options par défaut – pour des machines MacOS, je vous conseille de garder "Auto" pour le "Licensed Mode", cela vous permet de ne pas avoir à gérer les UIDs pour les comptes utilisateurs, par défaut dans ce mode, les UIDs générés dans la Zone Centrify seront un dérivé du SID utilisateur AD – vous pourrez ensuite aligner les UIDs générés dans cette zone avec les comptes utilisateurs existants au niveau de l’OS MacOS X via un outil fourni par centrify.

A noter que le premier ordinateur MacOS qui sera joint à AD avec le mode "Auto" va automatiquement créer la zone "Auto" au niveau de l’AD lui-même, contrairement aux systèmes Unix et Linux qui sont généralement joints dans des zones « standards », il n’y a pas besoin ici de créer la zone en amont de la première jointure au domaine.

Puis cliquer sur "Join"

clip_image044

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image045

L’assistant indique que la machine est en train de rejoindre le domaine AD:

clip_image047

Tout s’est bien déroulé, cliquer sur "Done":

clip_image049

Redémarrer le poste MacOS.

[3] – Première connexion avec un compte utilisateur AD

Sur la fenêtre de login du MacOS X, vosu trouverez par défaut les comptes locaux existants (ici Florent) – mais maintenant que vous avez joint la machine à AD, vous pourrez accéder à une liste d’utilisateurs provenant d’AD en cliquant sur "Other…"

clip_image051

Par exemple, nous avons un compte utilisateur existant dans AD qui est Luc:

clip_image053

Nous allons utiliser ce compte et son mot de passe AD pour nous connecter sur la machine MacOS X:

clip_image055

Un nouveau bureau pour Luc apparait :

clip_image057

Si nous utilisons une fenêtre de Terminal, et que l’on taper la commande ‘id’ on obtient les informations suivantes, l’UID a été automatiquement généré pour l’utilisateur :

clip_image059

Toujours dans le terminal, la commande ‘adinfo’ nous permet d’obtenir des informations sur la connectivité à AD:

clip_image061

Ça y est, c’est officiel, notre machine MacOS X EL CAPITAN a rejoint AD et peut utiliser tous les services AD.

Dans les prochains articles, nous allons explorer quelques pistes d’améliorations du paramétrage de base, utiliser quelques outils d’administration et nous allons explorer les GPOs applicables aux systèmes MacOS X.

Directory as a Service, c’est parti !

AzureADDoma1Ça y est ! Microsoft rend public Azure AD Domain Services (à ne pas confondre avec Azure AD ou avec le fait d’installer un DC sur la plateforme IAAS d’Azure… Bon, je sais, ca devient un peu compliqué) qui est la première brique d’une approche qui fait fantasmer énormément de monde: le Directory As A Service ou DaaS. Alors oui, vous allez me dire le DaaS c’est aussi le « Data as a Service », le « Desktop as a service », etc… bon d’accord, alors écrivons le comme cela: DIRaaS, cela sera plus clair…

Donc pour faire simple, Microsoft rend public un nouveau service Azure permettant de créer un service online « simulant » un Active Directory dans Azure (côté SaaS, pas côté IaaS): Azure AD Domain Services. Les objectifs de ce service sont multiples:

(1) Permettre aux entreprise qui possèdent des applications AD dépendantes dans l’IaaS d’Azure (donc des applications hébergées sur des machines virtuelles Azure pour faire simple) de consommer un service Active Directory standard (enfin presque…) sans être obligé d’installer et de maintenir des DCs sur des machines virtuelles Azure uniquement pour des besoins applicatifs

(2) Permettre à des petites entreprises de pouvoir TOUT consommer sous la forme de service d’infrastructure depuis la plateforme Azure – Mais attention, à ce stade il n’est possible que de joindre des machines qui sont des VMs dans Azure, donc ici, pas possible de joindre un domaine Azure AD Domain Services depuis par exemple une machine Windows 10 qui est « on premises » (alors que cette fonction existe avec AD Azure, oui je sais c’est un peu compliqué…)

(3) A terme, fournir un véritable DIRaaS pour les grandes entreprises. Sur ce point, oui, je sais,  j’extrapole, mais je sens bien les choses comme cela, et franchement c’est assez intéressant. Bien sur il y a encore pas mal de dev à faire, mais cela va venir, j’en suis persuadé…

Faire des tests !

En effet, dans le cadre de la gestion de VMs qui sont dans Azure et qui possèdent des applications dépendantes à AD, il faut voir globalement le service Azure AD Domain Services comme un service qui expose les protocoles Kerberos, NTLM, LDAP et GPOs – les VMs Azure peuvent donc joindre ce domaine. Mais attention, on est pas ici exactement comme un domaine AD, donc il est important de faire des tests pour valider que vos applications sont fonctionelles dans ce contexte technique et être certain qu’elles fonctionnent avec ce service – à ce jour, je ne suis pas sur qu’il existe un catalogue officiel d’applications certifiées pour le service, cela viendra certainement.

En bref.

Super intéressant, à tester. Plus d’informations [ ici ]

389 Directory Server 1.3.1.10

389Directoryserver

 

Le projet Fedora vient de mettre en ligne la version 1.3.1.10 de 389 Directory Server. Cette nouvelle version est téléchargeable [ ici ] – vous y trouverez aussi les notes d’information sur les nouveautés.

Pour moi, le plus « gros bug » corrigé est celui-ci:  » Ticket #47492 – PassSync removes User must change password flag on the Windows side  « 

En effet, lors de la synchronisation vers Active Directory (module encore largement perfectible !) , un bug éliminait le besoin pour un utilisateur de changer son mot de passe au niveau d’Active Directory, plutôt ennuyeux…

Globalement, je suis assez déçu par ce produit, plein de promesses au départ, les trop nombreux bugs au niveau des modules de synchronisation ont eut raison de ma patience… FIM est peut être payant, mais cela fonctionne et il y a du support…

 

La 4ème conférence internationale sur LDAP aura lieu à Paris !

ldapcon_2013_logo_line

 

 

 

La 4ème conférence internationale sur LDAP aura lieu à Paris, les 18 & 19 Novembre 2013 dans les locaux de la Maison des Associations de Solidarité. L’entrée est de 250€ par personne pour 2 jours, ou 180€ par personne pour une réservation avant le 15 Septembre 2013.

Les thèmes suivants seront au cœur des discussions et présentations:

  • Pure LDAP technology implementation (Servers, API, etc.)
  • LDAP Usage (Security, web development, big data, etc.)
  • LDAP related technologies (PKI, XACML, SAML, etc.)
  • LDAP and Beyond (IAM, Identity Federation, Authentication on the web, etc.)

Les inscriptions sont accessibles [ ici ]

Sortie de Oracle Identity Management 11g Release 2

  La version Oracle Identity Management 11g Release 2 vient de sortir sur le marché. cette nouvelle version apporte principalement des avancées dans les quatre domaines suivants:

  • Gestion des privilèges multi-plateformes: sur cette partie, Oracle tente de rattraper son retard sur les solutions connues et reconnues du marché chez Quest, Centrify ou Avecto
  • Sécurisation de l’authentification sur les plateformes mobiles: A nouveau, Oracle me semble bien en retard par rapport aux produits présents sur le marché depuis plus d’un an chez Airwatch, MobileIron ou Centrify
  • Nouveautés sur la partie Fédération, et notamment dans les scénarios de SSO vers les applications en Cloud public telles que SalesForce, GoogleApps, etc…
  • Des nouveautés sur la virtualisation d’attributs dans Oracle Directory Services

Plus d’informations sur le site d’Oracle

Est ce que freeIPA est l’Active Directory de RedHat ?

redhat_freeIPA Apparu il y a quelques mois en version 1.0, la suite freeIPA est passée totalement inaperçue dans le monde de la gestion des identités et des accès. Et pourtant, la version 2.0 (pour l’instant en beta) propose une liste de fonctions qui rappelle fortement ce que propose Microsoft au travers d’Active Directory:

  • Service LDAP (anciennement Fedora Directory Server)
  • Service MIT Kerberos
  • Service NTP
  • Service DNS
  • Service d’autorité de certification
  • Interface d’administration en mode web ou en ligne de commandes
  • Gestion des comptes utilisateurs et des groupes

HighLevelArchV2

Avouez que la ressemblance est troublante…

J’ai pour habitude de dire qu’Active Directory, c’est trois éléments: [1] Un service LDAP [2] Un service Kerberos [3] Un ensemble d’autres choses…  Le tout proposé avec des outils d’administration et de gestion intégrés.

freeIPA 2.0 proposera en Mars 2011 des outils de synchronisation avec Active Directory, à voir la comparaison avec un méta-annuaire.

Mais, le véritable chalenge sera comme souvent l’intégration des clients… Active Directory possède pour l’instant la plus grande couverture fonctionnelle de clients qui puisse exister: Windows, Mac, Unix, Linux, tout est possible ! Il sera donc très important de tester l’intégration des clients lors du test éventuel de freeIPA en version 2.0.

Sortie de la version 2.1 pendant l’été 2011.

SSO pour les applications hébergées

oneloginJe suis tombé par hasard sur le site de OneLogin [ www.onelogin.com ] qui propose une offre qui me semble intéressante pour les utilisateurs d’applications hébergées nécessitant une authentification web. Le principe est relativement simple, l’utilisateur se connecte une fois sur la page de OneLogin, et il peut ensuite accéder à toutes les autres applications hébergées. Oui, je sais, ca existe déjà, mais il me semble que le nombre d’applications gérées nativement ( 1200+ ) et l’intégration possible avec un annuaire d’entreprise ( LDAP ou Active Directory ) me semble faire sortir cette offre du lot… A tester. Je suis intéressé par vos tests, retours et commentaires sur le sujet !

LDAP Synchronization Connector Project

LCS_project Lors d’un projet chez un client, j’ai re-découvert un projet Open Source permettant de réaliser des synchronisations simples en mode point à point entre deux annuaires LDAP ou entre une base de données et un annuaire LDAP. Attention, bien sur ce projet n’est PAS un méta-annuaire, ce n’est QUE de la synchronisation point à point. Néanmoins, sur des besoins de migration ou sur des besoins relativement simplistes de synchronisation, LSC sera une solution adaptée, tant que le client accepte d’utiliser des solutions Open Source sans support officiel autre que les forums de Source Forge.

A noter que la dernière version de LSC intègre des fonctions spécifiques à la gestion des identités et à la connexion avec Active Directory telles que la changement de mot de passe, le statut du compte ou la gestion de l’attribut « last logon ».

Donc malgré ses limitations inhérentes à un modèle de synchronisation point à point, LSC peut rendre des services sur des petits projets IAM ou de migration d’annuaires. Plus d’informations [ ici ]

Sortie de OpenDS en version 2.2

opends_logoMalgré le rachat par Oracle, les équipes de SUN semblent continuer le développement des logiciels OpenDS et OpenSSO. Il est vrai que ces deux briques sont des piliers essentiels de l’offre IAM de SUN et de son maintien sur le marché de la gestion des identités. La version 2.2 d’OpenDS peut être téléchargée sur le site web du projet et propose les nouveautés suivantes:

# Fonctions supplémentaires pour le panneau de configuration graphique:

  • Management des serveurs distants
  • Gestion des taches planifiées

# Amélioration du mécanisme de réplication:

  • Commande dsreplication pour gérer les réplications d’annuaire à large échelle
  • Support de la réplication fractionnée
  • Journaux des changements effectués

# Amélioration du mécanisme d’import depuis LDIF, dans le cas d’import en masse

# Amélioration du support des syntaxes et des règles(subsititution, expressions régulières, temps relatif, etc…)

# Amélioration du temps de traitement prou la construction de l’index des entrées dans des cas avec des annuaires très chargés

Il est clair que l’on perçoit très vite que l’objectif de SUN est de produire le meilleur annuaire possible en terme de performance et de gestion de la charge dans des environnements à très grand nombre d’entrées dans l’annuaire. En effet, ce fut l’un des écueils de SUNone. L’évolution de OpenDS et surtout les différentes décisions d’Oracle quand à la stratégie à appliquer vont nous fournir plus de lisibilité sur ce marché dans les mois à venir.

Migrer vos domaines NIS vers Active Directory

nis-migrationcom La migration NIS est une des problématiques majeures de l’ensemble des grands groupes que j’ai pu rencontrer. En effet, les domaines NIS ou NIS+ ne sont plus supportés par SUN, l’inventaire du protocole. De plus, le protocole d’authentification NIS n’étant pas sécurisé (en fait, vraiment pas sécurisé…), il est important de migrer pour des raisons sécuritaires ou pour des besoins de compatibilité SOX ou PCI.

Classiquement, le premier réflexe est d’imaginer migrer les informations contenues dans les domaines NIS ou NIS+ vers un annuaire LDAP. Après ce premier réflexe, les ennuis commencent… La première problématique étant bien évidemment la collision des UIDs. En effet, dans le monde réel (et pas celui de PowerPoint) un utilisateur physique unique possède plusieurs profils Unix en fonction du système sur lequel il doit se connecter, il est alors très compliqué de consolider potentiellement des dizaines d’UIDs vers un seul attribut UID stocké dans un annuaire LDAP.

C’est ici qu’Active Directory peut venir à l’aide des administrateurs ou architectes Unix !!! En effet, selon certaines conditions, il sera possible de migrer et conserver plusieurs UIDs dans l’annuaire Active Directory et ainsi conserver les accès aux ressources Unix sans modifier les UIDs sur l’ensemble des systèmes migrés.

Un site extrêmement bien construit www.nis-migration.com explique (en anglais) l’ensemble de la problématique et des possibilités techniques de la migration NIS -> Active Directory – Je reviendrais plus tard sur cette problématique très répandue dans les grands entreprises utilisant Unix ou Linux.

Sortie de la version « stable » 2.0.0 de SUN OpenDS

opends_logoSUN a annoncé la disponibilité de la version stable 2.0.0 de son annuaire OpenDS. OpenDS est un projet OpenSource ayant pour objectif de construire la nouvelle génération d’annuaire LDAP de chez SUN. OpenDS est basé sur les standard DSML et a été désigné pour supporter une quantité très importante de données et de transactions.

Pour la notion d’extensibilité de cet annuaire est le point le plus important. En effet, OpenDS a été construit pour permettre à des modules « externes » de venir se connecter au service d’annuaire et d’interagir avec lui. Une API est mise à disposition des futurs fournisseurs désirant développer des plug-ins additionnels sur l’annuaire.

La version 2.0.0 est téléchargeable [ ICI ]

Le WIKI du projet est consultable [ ICI ]