Sharepoint App store - problème alias cname et popup de login
Fermé
yakalelo57
Messages postés
103
Date d'inscription
mercredi 24 octobre 2012
Statut
Membre
Dernière intervention
19 février 2019
-
16 juin 2016 à 12:05
yakalelo57 Messages postés 103 Date d'inscription mercredi 24 octobre 2012 Statut Membre Dernière intervention 19 février 2019 - 20 juin 2016 à 15:09
yakalelo57 Messages postés 103 Date d'inscription mercredi 24 octobre 2012 Statut Membre Dernière intervention 19 février 2019 - 20 juin 2016 à 15:09
A voir également:
- Sharepoint App store - problème alias cname et popup de login
- Télécharger sans app store gratuit - Guide
- App data - Guide
- Telecharger microsoft store - Guide
- 94 jeu app store - Télécharger - Puzzle & Réflexion
- Facebook.com/login/identify en francais ✓ - Forum Réseaux sociaux
4 réponses
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
16 juin 2016 à 14:13
16 juin 2016 à 14:13
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.
yakalelo57
Messages postés
103
Date d'inscription
mercredi 24 octobre 2012
Statut
Membre
Dernière intervention
19 février 2019
1
17 juin 2016 à 23:22
17 juin 2016 à 23:22
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
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié par kelux le 18/06/2016 à 09:41
Modifié par kelux le 18/06/2016 à 09:41
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.
jolyjump3r
Messages postés
1827
Date d'inscription
mardi 8 novembre 2011
Statut
Membre
Dernière intervention
14 mars 2020
616
17 juin 2016 à 23:34
17 juin 2016 à 23:34
Peut que le Popup est de trop. Une simple page ferait l'affaire.
--
--
yakalelo57
Messages postés
103
Date d'inscription
mercredi 24 octobre 2012
Statut
Membre
Dernière intervention
19 février 2019
1
20 juin 2016 à 15:09
20 juin 2016 à 15:09
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...