Meilleur auteur de réponses
SP2K13 : Restriction d'accès à une Web Application

Question
-
Bonjour,
J'ai une ferme SharePoint 2013 qui comporte plusieurs Web Applications.
Sur certaines de ces Web Applications, je souhaiterai restreindre l'accès à un groupe d'utilisateurs.
Cette restriction ne doit pas être configurée sur les Collections de Sites mais bien au niveau de la Web Application.
J'ai bien note qu'il était possible d'utiliser une stratégie sur une Web Application qui permettrait d'appliquer un DENY ALL à un groupe d'utilisateurs (ce qui pourrait répondre au besoin) mais cela pose probleme car dans mon cas, il n'existe pas de groupe de sécurité correspondant. Je souhaiterai donc procéder de manière inverse : autoriser des personnes membres d'un groupe de sécurité AD à acceder à une Web Application.
Est-ce possible ?
Merci pour votre aide :)
Cordialement.
Réponses
-
J'insiste : votre démarche n'est pas bonne !
Comme je le disais et aussi Marc le souligne aussi Marc, le Deny All n'est pas conçu pour ça et vous risquez d'etre confronté à d'autres soucis
De plus du moment que vous faites "confiance" à un utilisateur pour créer des collection de sites et les administrer (et ce n'est pas rien) vous devez lui permettre de gérer (en toute confiance) les permissions. Si cette relation de confiance n'est pas faisable, vous ne devez pas déléguer la création de collections de site qui est loin d’être anodine (ajout dans une bdd de contenu, quotas, modèles...) ou sinon outillez vos utilisateurs avec des outils qui contrôlent régulièrement que les permissions accordées sont "compatibles" avec les directives de la DSI : ça s’appelle de la gouvernance ! (et il existe plein d'outils pour ça avec comme leader DocAve de AvePoint et Security Explorer de Quest par exemple)
Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel
- Marqué comme réponse Gokan OzcifciMVP jeudi 16 janvier 2014 07:24
-
Bonjour,
Je vous recommande la prudence dans l'usage du "Deny". Si un même utilisateur est membre de deux groupes, l'un utilisé pour autoriser l'accès et l'autre pour l'empêcher, alors le résultat effectif sera d'empêcher l'accès.
Un usage trop large du "Deny" pourrait même empêcher l'accès au compte(s) technique(s).
Marc Lognoul [Infrastructure Expert]
My Site/Mon Site | MyBlog [EN] | Mon Blog [FR] | Twitter | LinkedIn
- Marqué comme réponse Gokan OzcifciMVP jeudi 16 janvier 2014 07:24
Toutes les réponses
-
Bonjour,
EDIT : merci à Marc L pour le test : cette solution ne fonctionne pas, le deny prend le dessus ...Je n'ai pas testé, mais vous pouvez tenter un "deny all" pour "NT AUTHORITY\Authenticated Users" ou "NomDomaine\Domain Users", et autoriser votre groupe.
Mais comme on me l'a fait remarquer par mail, et avis que je partage, le deny risque de prendre le pas sûr le reste.Quelques posts apparentés :
My technical blog on SharePoint || My contributions on the TechNet Gallery
- Modifié Benoit Jester [MVP]MVP, Moderator samedi 11 janvier 2014 15:29
-
Bonjour
La création de collection de sites par défaut n'est pas accessible à n'importe qui mais seulement des admins de la ferme.
Il me semble plus judicieux de cadrer correctement "humainement" le process de création des collection pour ne mettre en droit d'accès que le groupe concerné plutôt que de vouloir détourner le système.
L'utilisation des "Users policy" est plus faite pour permettre à des admins d'avoir un droit de regard/accès sur des collections qui sont crées/gérées par d'autre personnes
Une autre approche serait de voir plus du côté de vos equipes qui gère l'AD pour qu'ils mettent en place le groupe dont vous avez besoin pour le "deny all"
Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel
- Proposé comme réponse lionel limozin lundi 13 janvier 2014 08:31
-
Bonjour,
Merci pour votre réponse.
L'approche "humaine" ne répond pas vraiment au probleme. La creation d'une Collection de Sites par des administrateurs permet certes de definir les droits initiaux. Cela étant, tout utilisateur peut ensuite attribuer des droits d'accès à sa guise sur les sites enfants et autoriser ainsi des personnes non autorisées initialement.
Manifestement, seule l'approche via le deny all semble donc pouvoir convenir.
-
Bonjour
pourquoi est-ce que tout utilisateur peut attribuer des droits d'accès ? vous ne devez pas faire ça quoiqu'il arrive !
SharePoint fourni des niveaux de droits pour différencier qui peut gérer les permissions et qui ne peut pas. Vous devez configurer vos groupes utilisateurs en fonction de cela....
Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel
-
Bonjour,
Je vous recommande la prudence dans l'usage du "Deny". Si un même utilisateur est membre de deux groupes, l'un utilisé pour autoriser l'accès et l'autre pour l'empêcher, alors le résultat effectif sera d'empêcher l'accès.
Un usage trop large du "Deny" pourrait même empêcher l'accès au compte(s) technique(s).
Marc Lognoul [Infrastructure Expert]
My Site/Mon Site | MyBlog [EN] | Mon Blog [FR] | Twitter | LinkedIn
- Marqué comme réponse Gokan OzcifciMVP jeudi 16 janvier 2014 07:24
-
Hello,
Dans mon cas, les administrateurs techniques (de la ferme) doivent avoir la certitude qu'un administrateur fonctionnel de Collection de Sites (qui peut donc attribuer des permissions) ne donnera pas accès à quelqu'un alors que ce n'est pas prévu, par la DSI.
L'administrateur technique qui gère la Web Application a donc cette capacité et cette garantie au travers du DENY ALL par exemple, qui semble être la seule solution à ce probleme.
Comme souvent, les equips de sécurité ont une notion de confiance relative ce qui m'empeche de proposer de "faire confiance" aux administrateurs de collections de sites.
Merci à tous pour vos points de vue en tt cas :)
-
J'insiste : votre démarche n'est pas bonne !
Comme je le disais et aussi Marc le souligne aussi Marc, le Deny All n'est pas conçu pour ça et vous risquez d'etre confronté à d'autres soucis
De plus du moment que vous faites "confiance" à un utilisateur pour créer des collection de sites et les administrer (et ce n'est pas rien) vous devez lui permettre de gérer (en toute confiance) les permissions. Si cette relation de confiance n'est pas faisable, vous ne devez pas déléguer la création de collections de site qui est loin d’être anodine (ajout dans une bdd de contenu, quotas, modèles...) ou sinon outillez vos utilisateurs avec des outils qui contrôlent régulièrement que les permissions accordées sont "compatibles" avec les directives de la DSI : ça s’appelle de la gouvernance ! (et il existe plein d'outils pour ça avec comme leader DocAve de AvePoint et Security Explorer de Quest par exemple)
Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel
- Marqué comme réponse Gokan OzcifciMVP jeudi 16 janvier 2014 07:24
-