Sharepoint App store - problème alias cname et popup de login
yakalelo57
Messages postés
110
Statut
Membre
-
yakalelo57 Messages postés 110 Statut Membre -
yakalelo57 Messages postés 110 Statut Membre -
Bonjour,
Je me permets de poste par ici car j'ai rencontré récemment un problème pour activer SharePoint App store en suivant une procédure trouvée sur Internet :
http://vlecerf.com/fr_FR/blog/2013/04/11/sharepoint-2013-configuration-du-sharepoint-app-store/
J'ai créé un alias CNAME comme indiqué sur la copie d'écran :
Nom de l'alias : *
Nom de domaine pleinement qualifié (FQDN) pour l’hôte de destination : SRV57.labtech.local
SRV57 est mon nom de serveur
labtech.local est mon domaine
Mon problème : une fois cet alias en place j'ai des popups sur mes postes clients qui les invitent à saisir un login et un mot de passe dès lors qu'ils essaient d'utiliser une ressource web (ouverture navigateur, site web, certains PDF aussi car adobe possède une partie web maintenant,...)
Je précise que j'ai une authentification de type spnego silencieuse pour les utilisateurs lorsqu'ils veulent sortir sur internet (firewall interne).
Je suppose donc que le conflit avec cet alias CNAME pourrait se situer par ici.
Quelqu'un aurait une idée ?
Mon alias est-il mal créé ?
Je me permets de poste par ici car j'ai rencontré récemment un problème pour activer SharePoint App store en suivant une procédure trouvée sur Internet :
http://vlecerf.com/fr_FR/blog/2013/04/11/sharepoint-2013-configuration-du-sharepoint-app-store/
J'ai créé un alias CNAME comme indiqué sur la copie d'écran :
Nom de l'alias : *
Nom de domaine pleinement qualifié (FQDN) pour l’hôte de destination : SRV57.labtech.local
SRV57 est mon nom de serveur
labtech.local est mon domaine
Mon problème : une fois cet alias en place j'ai des popups sur mes postes clients qui les invitent à saisir un login et un mot de passe dès lors qu'ils essaient d'utiliser une ressource web (ouverture navigateur, site web, certains PDF aussi car adobe possède une partie web maintenant,...)
Je précise que j'ai une authentification de type spnego silencieuse pour les utilisateurs lorsqu'ils veulent sortir sur internet (firewall interne).
Je suppose donc que le conflit avec cet alias CNAME pourrait se situer par ici.
Quelqu'un aurait une idée ?
Mon alias est-il mal créé ?
A voir également:
- Sharepoint App store - problème alias cname et popup de login
- App data - Guide
- Télécharger sans app store gratuit - Guide
- Telecharger microsoft store - Guide
- Vidmate app - Télécharger - TV & Vidéo
- Fake mcafee popup - Accueil - Piratage
4 réponses
Hello,
Je connais pas du tout SP App Store.
Le seul truc qui me vient à l'esprit est le SPN de l'alias sur le serveur en question, est il bien déclaré ?
https://4sysops.com/archives/sharepoint-kerberos-authentication/
Sinon je n'ai pas d'autres idées.
Je connais pas du tout SP App Store.
Le seul truc qui me vient à l'esprit est le SPN de l'alias sur le serveur en question, est il bien déclaré ?
https://4sysops.com/archives/sharepoint-kerberos-authentication/
Sinon je n'ai pas d'autres idées.
bon alors à priori je pense que ça venait de l'alias en *
je l'ai nommé *.apps.
du coup ping test.apps.mondomaine.fr répond bien.
Et je n'ai plus de popups de demande d'authentification.
Je pense que les tutos avec alias cname * sont bien pour un environnement à la maison avec un serveur qui fait sharepoint + AD (et un poste client derrière).
Mais en entreprise avec toute une archi derrière c'est pas pareil.
Quelqu'un pourra me confirmer peut être mais l'alias cname en * est trop générique tandis que *.apps permet de limiter grandement les réponses sur cet alias
je l'ai nommé *.apps.
du coup ping test.apps.mondomaine.fr répond bien.
Et je n'ai plus de popups de demande d'authentification.
Je pense que les tutos avec alias cname * sont bien pour un environnement à la maison avec un serveur qui fait sharepoint + AD (et un poste client derrière).
Mais en entreprise avec toute une archi derrière c'est pas pareil.
Quelqu'un pourra me confirmer peut être mais l'alias cname en * est trop générique tandis que *.apps permet de limiter grandement les réponses sur cet alias
Hello,
Je suppose que : s'il y a popup, c'est que ça passe en NTLM et non en Kerberos.
Donc il y a probablement un souci de SPN.
Quand tu passes avec le nom en Wildcard (le *.apps.domain.local)., ba il n'y pas ce souci , ça prend n'importe quel nom d'un nom déja connu (et dans les SPN).
Il faudrait voir comment les URL sont faites.
J'ai l'impression que les URL sont générées "aléatoirement" - d'où la nécessité d'avoir un wildcard.
Par contre c'est problématique, car si on souhaite du SSL, il faut aussi un certificat Wildcard. Certaines boites n'autorisent pas le Wildcard (enfin la sécu ...) et ça coute plus cher si le sharepoint est exposé sur le net (certificat d'une autorité externe).
-
Ici le type prend un "sous domaine" *.apps.domain.local
Donc c'est mieux , que de prendre un nouveau nom de domaine différent comme j'ai pu le voir sur d'autres tutoriels - tu auras moins de soucis avec les SPN aussi.
http://sharepointchick.com/archive/2012/07/29/setting-up-your-app-domain-for-sharepoint-2013.aspx
Regarde aussi bien le dernier paragraphe, ça peut t'éclairer sur des futures problématiques.
-
Revenant à ta problématique de départ : si tu ne déclares pas le SPN que tu utilises pour joindre un service par son nom, l'authentification via Kerberos est pas active pour le nom en question. Je m'explique :
URL : intranet.domain.local
Srv Web réel : srv57.domain.local
tu auras plusieurs SPN, la liste "ressemblerait" à ça :
HTTP/intranet.domain.local domain\svcaccount
HTTP/intranet domain\svcaccount
HTTP/srv57.domain.local domain\svcaccount
HTTP/srv57 domain\svcaccount
En gros ça décrit quel service (HTTP) peut faire de l'authent Kerberos à partir de quel nom (nom court ou FQDN) et avec quel identité (le compte de service - qui peut être un compte système)
Tu en as sur des domain controllers, sur des serveurs SQL, Web etc ... et même sur des Apache tournant sous Linux ... en utilisant des fichiers Keytab.
En du gros tu files un fichier Keytab que tu bricoles sur un Apache tournant sous Linux, l'apache sera capable d'authentifier via Kerberos des utilisateurs AD (sous réserve d'avoir les packages etc ...)
https://support.microsoft.com/fr-fr/help/555092
Sur des sites IIS en équilibrage de charge, tu es obligé de le faire si tu veux utiliser l'authent Kerberos - tout comme un cluster SQL and co ...
Car le nom avec lequel tu attaques le service est différent de celui de l’hôte réel, donc le SPN n'est pas créé automatiquement - il faut l'ajouter à la main - sinon le service ne peut pas utiliser l'authentification Kerberos - ni pour lui et les demandes d'authent des clients ; d'où un joli popup ;-)
-
J'ai peut être botté à coté, mais ça te donne des informations supplémentaires pour comprendre la problématique de départ.
donc pour finir le *.apps.domain.local est la bonne configuration pour ton SP Appstore.
Je suppose que : s'il y a popup, c'est que ça passe en NTLM et non en Kerberos.
Donc il y a probablement un souci de SPN.
Quand tu passes avec le nom en Wildcard (le *.apps.domain.local)., ba il n'y pas ce souci , ça prend n'importe quel nom d'un nom déja connu (et dans les SPN).
Il faudrait voir comment les URL sont faites.
J'ai l'impression que les URL sont générées "aléatoirement" - d'où la nécessité d'avoir un wildcard.
Par contre c'est problématique, car si on souhaite du SSL, il faut aussi un certificat Wildcard. Certaines boites n'autorisent pas le Wildcard (enfin la sécu ...) et ça coute plus cher si le sharepoint est exposé sur le net (certificat d'une autorité externe).
-
Ici le type prend un "sous domaine" *.apps.domain.local
Donc c'est mieux , que de prendre un nouveau nom de domaine différent comme j'ai pu le voir sur d'autres tutoriels - tu auras moins de soucis avec les SPN aussi.
http://sharepointchick.com/archive/2012/07/29/setting-up-your-app-domain-for-sharepoint-2013.aspx
Regarde aussi bien le dernier paragraphe, ça peut t'éclairer sur des futures problématiques.
-
Revenant à ta problématique de départ : si tu ne déclares pas le SPN que tu utilises pour joindre un service par son nom, l'authentification via Kerberos est pas active pour le nom en question. Je m'explique :
URL : intranet.domain.local
Srv Web réel : srv57.domain.local
tu auras plusieurs SPN, la liste "ressemblerait" à ça :
HTTP/intranet.domain.local domain\svcaccount
HTTP/intranet domain\svcaccount
HTTP/srv57.domain.local domain\svcaccount
HTTP/srv57 domain\svcaccount
En gros ça décrit quel service (HTTP) peut faire de l'authent Kerberos à partir de quel nom (nom court ou FQDN) et avec quel identité (le compte de service - qui peut être un compte système)
Tu en as sur des domain controllers, sur des serveurs SQL, Web etc ... et même sur des Apache tournant sous Linux ... en utilisant des fichiers Keytab.
En du gros tu files un fichier Keytab que tu bricoles sur un Apache tournant sous Linux, l'apache sera capable d'authentifier via Kerberos des utilisateurs AD (sous réserve d'avoir les packages etc ...)
https://support.microsoft.com/fr-fr/help/555092
Sur des sites IIS en équilibrage de charge, tu es obligé de le faire si tu veux utiliser l'authent Kerberos - tout comme un cluster SQL and co ...
Car le nom avec lequel tu attaques le service est différent de celui de l’hôte réel, donc le SPN n'est pas créé automatiquement - il faut l'ajouter à la main - sinon le service ne peut pas utiliser l'authentification Kerberos - ni pour lui et les demandes d'authent des clients ; d'où un joli popup ;-)
-
J'ai peut être botté à coté, mais ça te donne des informations supplémentaires pour comprendre la problématique de départ.
donc pour finir le *.apps.domain.local est la bonne configuration pour ton SP Appstore.
l'histoire du popup c'était l'alias CNAME générique en * et l'authentification transparente du firewall sur les postes clients qui entraient en conflit.
En mettant *.apps je n'ai plus le problème mentionné.
Par contre j'ai terminé la configuration selon le tutoriel ici :
http://vlecerf.com/fr_FR/blog/2013/04/11/sharepoint-2013-configuration-du-sharepoint-app-store/
Mes services sont créés et démarrés avec un SPManaged account spécialement créé pour (compte du domaine).
Tout tourne bien semblerait-il mais lorsque je tente d'ouvrir le SharePoint Store j'ai un message qui dit "désolé il semble que nous ne puissions pas nous connecter au sharepoint store"
La première tentative a pris 50-60 secondes avec un genre de sablier de recherche alors que les fois suivantes le message était immédiat.
Quelqu'un aurait-il une idée de ce que j'aurais raté et éventuellement de ce qu'il faudrait revérifier dans la config car là aucune idée...
En mettant *.apps je n'ai plus le problème mentionné.
Par contre j'ai terminé la configuration selon le tutoriel ici :
http://vlecerf.com/fr_FR/blog/2013/04/11/sharepoint-2013-configuration-du-sharepoint-app-store/
Mes services sont créés et démarrés avec un SPManaged account spécialement créé pour (compte du domaine).
Tout tourne bien semblerait-il mais lorsque je tente d'ouvrir le SharePoint Store j'ai un message qui dit "désolé il semble que nous ne puissions pas nous connecter au sharepoint store"
La première tentative a pris 50-60 secondes avec un genre de sablier de recherche alors que les fois suivantes le message était immédiat.
Quelqu'un aurait-il une idée de ce que j'aurais raté et éventuellement de ce qu'il faudrait revérifier dans la config car là aucune idée...
