je souhaite mettre en place un serveur WSS3 derrière un FW pour en faire un
extranet, je voudrais qu'il soit membre de mon domaine AD (dont les DC se
situent dans le réseau interne) pour que les users internes puissent s'y
authentifier via AD. Je pensais ensuite créer des comptes au cas par cas en
local sur le serveur extranet pour les utilisateurs externes (histoire de pas
trop polluer mon AD).
J'ai bien ouvert quelques port sur le FW (389,445,88,135) mais ca ne marche
toujours pas (j'arrive pas a associer mon serveur extanet au domaine). J'ai
vu qu'il fallait peut-etre fixer le port de RPC (aléatoire par défaut) en
bidouillant des clés des DC mais là franchement, ca ne m'inspire pas
confiance (j'ai pas de palteforme de test, c'est de la prod !). D'ailleurs
j'ai pas bien compris si il fallait fixer le port RPC sur TOUS les dc ou
juste un seul DC modifié suffisait (le seul qui serait pointé dans la dns de
mon extranet par exemple).
Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette
bidouille RPC en terme de compatibilité avec tout le tralala AD compatible
(GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lognoul, Marc \(Private\)
Bonjour,
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ, cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq suggestions...
Solution #1: Ouvrir les ports: TCP135 (MS-RPC End-point mapper) TCP 1025 (RPC high port DRSUAPI...) TCP 1026 (RPC high port DRSUAPI...) TCP 389 (LDAP) TCP 3268 (LDAP Global Catalog) TCP + UDP 53 (DNS + DynDNS) TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes) TCP 139 (SMB) UDP 137 UDP 138 (WINS, NetBIOS...) TCP + UDP 88 (Kerberos v5 + Kerberos large PAC) ICMP (="large pings" inclus) + le port fixé pour netlogon + le port 25 vers votre serveur email -> en conclusion, cela n'apporte rien en terme de sécurité puisque votre firewall est une passoir et expose votre AD. SharePoint compromis = AD compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres serveurs) Joindre le serveur au domain alors qu'il est tjrs sur le LAN Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et vers tous les serveurs Placer le serveur dans la DMZ et tester la connectivité -> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de sécurité
Solution #3: Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall. NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose en terme de sécurité car il n'inspecte pas le protocole à moins d'y adjoindre un plug-in Un seul port à ouvrir (port 80). Ce type de firewall peut également établir le tunnel SSL au lieu d'IIS.
Solution #4 Conserver le SharePoint dans un workgroup et créer des comptes locaux pour les internes et les externes. Pour les internes, veillez à utiliser le même nom+mot de passe afin de bénéficier du pass-through authentication de Windows Un seul port à ouvrir (port 80) en inbound uniquement -> la solution la plus sur, Sharepoint compromis = pas de propagation dans le réseau interne. Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas Oui cela peut être fastidieux de maintenir la correspondance entre AD interne et compte locaux sur le SharePoint MAIS il existe des outils de synchronisation ET la sécurité a un prix
Solution #5 Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer la même recette que pour #4. L'AD offre l'avantage être plus facilement "synchronizable" qua la SAM database locale
Solution #6 Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir http://support.microsoft.com/kb/179442/fr) Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound -> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les solutions précédente mais...
Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette bidouille RPC en terme de compatibilité avec tout le tralala AD compatible (GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.)
Tous ces services ou technologies Windows requièrent d'ouvrir des port ou des destination additionnelle sur le firewall et donc, des problème de compatibilité potentiels. Pense également à votre "pauvre" firewall qui va souffrir de toutes ces connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Bonjour,
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ,
cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq
suggestions...
Solution #1: Ouvrir les ports:
TCP135 (MS-RPC End-point mapper)
TCP 1025 (RPC high port DRSUAPI...)
TCP 1026 (RPC high port DRSUAPI...)
TCP 389 (LDAP)
TCP 3268 (LDAP Global Catalog)
TCP + UDP 53 (DNS + DynDNS)
TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes)
TCP 139 (SMB)
UDP 137
UDP 138 (WINS, NetBIOS...)
TCP + UDP 88 (Kerberos v5 + Kerberos large PAC)
ICMP (="large pings" inclus)
+ le port fixé pour netlogon
+ le port 25 vers votre serveur email
-> en conclusion, cela n'apporte rien en terme de sécurité puisque votre
firewall est une passoir et expose votre AD. SharePoint compromis = AD
compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres
serveurs)
Joindre le serveur au domain alors qu'il est tjrs sur le LAN
Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et
vers tous les serveurs
Placer le serveur dans la DMZ et tester la connectivité
-> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de
sécurité
Solution #3:
Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall.
NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose
en terme de sécurité car il n'inspecte pas le protocole à moins d'y
adjoindre un plug-in
Un seul port à ouvrir (port 80). Ce type de firewall peut également établir
le tunnel SSL au lieu d'IIS.
Solution #4
Conserver le SharePoint dans un workgroup et créer des comptes locaux pour
les internes et les externes. Pour les internes, veillez à utiliser le même
nom+mot de passe afin de bénéficier du pass-through authentication de
Windows
Un seul port à ouvrir (port 80) en inbound uniquement
-> la solution la plus sur, Sharepoint compromis = pas de propagation dans
le réseau interne. Veillez à forcer un reste des mots de passes de votre AD
interne dans ce cas
Oui cela peut être fastidieux de maintenir la correspondance entre AD
interne et compte locaux sur le SharePoint MAIS il existe des outils de
synchronisation ET la sécurité a un prix
Solution #5
Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer
la même recette que pour #4. L'AD offre l'avantage être plus facilement
"synchronizable" qua la SAM database locale
Solution #6
Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir
un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne
Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir
http://support.microsoft.com/kb/179442/fr)
Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound
-> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les
solutions précédente mais...
Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette
bidouille RPC en terme de compatibilité avec tout le tralala AD compatible
(GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.)
Tous ces services ou technologies Windows requièrent d'ouvrir des port ou
des destination additionnelle sur le firewall et donc, des problème de
compatibilité potentiels.
Pense également à votre "pauvre" firewall qui va souffrir de toutes ces
connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera
vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne
réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ, cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq suggestions...
Solution #1: Ouvrir les ports: TCP135 (MS-RPC End-point mapper) TCP 1025 (RPC high port DRSUAPI...) TCP 1026 (RPC high port DRSUAPI...) TCP 389 (LDAP) TCP 3268 (LDAP Global Catalog) TCP + UDP 53 (DNS + DynDNS) TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes) TCP 139 (SMB) UDP 137 UDP 138 (WINS, NetBIOS...) TCP + UDP 88 (Kerberos v5 + Kerberos large PAC) ICMP (="large pings" inclus) + le port fixé pour netlogon + le port 25 vers votre serveur email -> en conclusion, cela n'apporte rien en terme de sécurité puisque votre firewall est une passoir et expose votre AD. SharePoint compromis = AD compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres serveurs) Joindre le serveur au domain alors qu'il est tjrs sur le LAN Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et vers tous les serveurs Placer le serveur dans la DMZ et tester la connectivité -> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de sécurité
Solution #3: Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall. NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose en terme de sécurité car il n'inspecte pas le protocole à moins d'y adjoindre un plug-in Un seul port à ouvrir (port 80). Ce type de firewall peut également établir le tunnel SSL au lieu d'IIS.
Solution #4 Conserver le SharePoint dans un workgroup et créer des comptes locaux pour les internes et les externes. Pour les internes, veillez à utiliser le même nom+mot de passe afin de bénéficier du pass-through authentication de Windows Un seul port à ouvrir (port 80) en inbound uniquement -> la solution la plus sur, Sharepoint compromis = pas de propagation dans le réseau interne. Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas Oui cela peut être fastidieux de maintenir la correspondance entre AD interne et compte locaux sur le SharePoint MAIS il existe des outils de synchronisation ET la sécurité a un prix
Solution #5 Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer la même recette que pour #4. L'AD offre l'avantage être plus facilement "synchronizable" qua la SAM database locale
Solution #6 Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir http://support.microsoft.com/kb/179442/fr) Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound -> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les solutions précédente mais...
Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette bidouille RPC en terme de compatibilité avec tout le tralala AD compatible (GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.)
Tous ces services ou technologies Windows requièrent d'ouvrir des port ou des destination additionnelle sur le firewall et donc, des problème de compatibilité potentiels. Pense également à votre "pauvre" firewall qui va souffrir de toutes ces connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Eddie Iannuccelli
Merci pour l'exhaustivité de ta réponse, je sais tout de suite que je vais choisir la solution , hum ... (suspens) : la solution 4 !!! (J'ai pas envie de me facher avec l'admin réseau ici qui se bat tout les jours avec ses briques Lucent). Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas " ? Dernière chose, quelles solutions existent pour synchroniser SAM et AD ? Encore merci pour ta réponse qui va effectivement m'eviter du sang et des larmes ;)
"Lognoul, Marc (Private)" wrote:
Bonjour,
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ, cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq suggestions...
Solution #1: Ouvrir les ports: TCP135 (MS-RPC End-point mapper) TCP 1025 (RPC high port DRSUAPI...) TCP 1026 (RPC high port DRSUAPI...) TCP 389 (LDAP) TCP 3268 (LDAP Global Catalog) TCP + UDP 53 (DNS + DynDNS) TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes) TCP 139 (SMB) UDP 137 UDP 138 (WINS, NetBIOS...) TCP + UDP 88 (Kerberos v5 + Kerberos large PAC) ICMP (="large pings" inclus) + le port fixé pour netlogon + le port 25 vers votre serveur email -> en conclusion, cela n'apporte rien en terme de sécurité puisque votre firewall est une passoir et expose votre AD. SharePoint compromis = AD compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres serveurs) Joindre le serveur au domain alors qu'il est tjrs sur le LAN Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et vers tous les serveurs Placer le serveur dans la DMZ et tester la connectivité -> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de sécurité
Solution #3: Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall. NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose en terme de sécurité car il n'inspecte pas le protocole à moins d'y adjoindre un plug-in Un seul port à ouvrir (port 80). Ce type de firewall peut également établir le tunnel SSL au lieu d'IIS.
Solution #4 Conserver le SharePoint dans un workgroup et créer des comptes locaux pour les internes et les externes. Pour les internes, veillez à utiliser le même nom+mot de passe afin de bénéficier du pass-through authentication de Windows Un seul port à ouvrir (port 80) en inbound uniquement -> la solution la plus sur, Sharepoint compromis = pas de propagation dans le réseau interne. Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas Oui cela peut être fastidieux de maintenir la correspondance entre AD interne et compte locaux sur le SharePoint MAIS il existe des outils de synchronisation ET la sécurité a un prix
Solution #5 Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer la même recette que pour #4. L'AD offre l'avantage être plus facilement "synchronizable" qua la SAM database locale
Solution #6 Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir http://support.microsoft.com/kb/179442/fr) Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound -> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les solutions précédente mais...
> Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette > bidouille RPC en terme de compatibilité avec tout le tralala AD compatible > (GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.) Tous ces services ou technologies Windows requièrent d'ouvrir des port ou des destination additionnelle sur le firewall et donc, des problème de compatibilité potentiels. Pense également à votre "pauvre" firewall qui va souffrir de toutes ces connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Merci pour l'exhaustivité de ta réponse, je sais tout de suite que je vais
choisir la solution , hum ... (suspens) : la solution 4 !!! (J'ai pas
envie de me facher avec l'admin réseau ici qui se bat tout les jours avec ses
briques Lucent).
Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes de
votre AD interne dans ce cas " ?
Dernière chose, quelles solutions existent pour synchroniser SAM et AD ?
Encore merci pour ta réponse qui va effectivement m'eviter du sang et des
larmes ;)
"Lognoul, Marc (Private)" wrote:
Bonjour,
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ,
cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq
suggestions...
Solution #1: Ouvrir les ports:
TCP135 (MS-RPC End-point mapper)
TCP 1025 (RPC high port DRSUAPI...)
TCP 1026 (RPC high port DRSUAPI...)
TCP 389 (LDAP)
TCP 3268 (LDAP Global Catalog)
TCP + UDP 53 (DNS + DynDNS)
TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes)
TCP 139 (SMB)
UDP 137
UDP 138 (WINS, NetBIOS...)
TCP + UDP 88 (Kerberos v5 + Kerberos large PAC)
ICMP (="large pings" inclus)
+ le port fixé pour netlogon
+ le port 25 vers votre serveur email
-> en conclusion, cela n'apporte rien en terme de sécurité puisque votre
firewall est une passoir et expose votre AD. SharePoint compromis = AD
compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres
serveurs)
Joindre le serveur au domain alors qu'il est tjrs sur le LAN
Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et
vers tous les serveurs
Placer le serveur dans la DMZ et tester la connectivité
-> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de
sécurité
Solution #3:
Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall.
NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose
en terme de sécurité car il n'inspecte pas le protocole à moins d'y
adjoindre un plug-in
Un seul port à ouvrir (port 80). Ce type de firewall peut également établir
le tunnel SSL au lieu d'IIS.
Solution #4
Conserver le SharePoint dans un workgroup et créer des comptes locaux pour
les internes et les externes. Pour les internes, veillez à utiliser le même
nom+mot de passe afin de bénéficier du pass-through authentication de
Windows
Un seul port à ouvrir (port 80) en inbound uniquement
-> la solution la plus sur, Sharepoint compromis = pas de propagation dans
le réseau interne. Veillez à forcer un reste des mots de passes de votre AD
interne dans ce cas
Oui cela peut être fastidieux de maintenir la correspondance entre AD
interne et compte locaux sur le SharePoint MAIS il existe des outils de
synchronisation ET la sécurité a un prix
Solution #5
Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer
la même recette que pour #4. L'AD offre l'avantage être plus facilement
"synchronizable" qua la SAM database locale
Solution #6
Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir
un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne
Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir
http://support.microsoft.com/kb/179442/fr)
Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound
-> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les
solutions précédente mais...
> Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette
> bidouille RPC en terme de compatibilité avec tout le tralala AD compatible
> (GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.)
Tous ces services ou technologies Windows requièrent d'ouvrir des port ou
des destination additionnelle sur le firewall et donc, des problème de
compatibilité potentiels.
Pense également à votre "pauvre" firewall qui va souffrir de toutes ces
connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera
vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne
réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
Merci pour l'exhaustivité de ta réponse, je sais tout de suite que je vais choisir la solution , hum ... (suspens) : la solution 4 !!! (J'ai pas envie de me facher avec l'admin réseau ici qui se bat tout les jours avec ses briques Lucent). Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas " ? Dernière chose, quelles solutions existent pour synchroniser SAM et AD ? Encore merci pour ta réponse qui va effectivement m'eviter du sang et des larmes ;)
"Lognoul, Marc (Private)" wrote:
Bonjour,
A chaque fois que j'ai vu cette configuration pour WSS/MOSS dans une DMZ, cela s'est terminé par du sang et des larmes :)
Si votre SharePoint consiste bien en un seul serveur WSS+SQL, voici qq suggestions...
Solution #1: Ouvrir les ports: TCP135 (MS-RPC End-point mapper) TCP 1025 (RPC high port DRSUAPI...) TCP 1026 (RPC high port DRSUAPI...) TCP 389 (LDAP) TCP 3268 (LDAP Global Catalog) TCP + UDP 53 (DNS + DynDNS) TCP 445 (CIFS/SMB + DFS + Microsoft-DS + pipes) TCP 139 (SMB) UDP 137 UDP 138 (WINS, NetBIOS...) TCP + UDP 88 (Kerberos v5 + Kerberos large PAC) ICMP (="large pings" inclus) + le port fixé pour netlogon + le port 25 vers votre serveur email -> en conclusion, cela n'apporte rien en terme de sécurité puisque votre firewall est une passoir et expose votre AD. SharePoint compromis = AD compromis, AD compromis = tout le reste compromis
Solution #2: Utiliser un tunnel IPSec entre SharePoint et AD (voire d'autres serveurs) Joindre le serveur au domain alors qu'il est tjrs sur le LAN Appliquer une policy IPSec à tous les ports excepté DNS et Kerberos, de et vers tous les serveurs Placer le serveur dans la DMZ et tester la connectivité -> beaucoup moins de ports à ouvrir (3) mais même conclusions en terme de sécurité
Solution #3: Placer votre SharePoint sur le LAN et utiliser un Web Application Firewall. NON pas un reverse-proxy style ISA qui n'apporte finalement pas grand-chose en terme de sécurité car il n'inspecte pas le protocole à moins d'y adjoindre un plug-in Un seul port à ouvrir (port 80). Ce type de firewall peut également établir le tunnel SSL au lieu d'IIS.
Solution #4 Conserver le SharePoint dans un workgroup et créer des comptes locaux pour les internes et les externes. Pour les internes, veillez à utiliser le même nom+mot de passe afin de bénéficier du pass-through authentication de Windows Un seul port à ouvrir (port 80) en inbound uniquement -> la solution la plus sur, Sharepoint compromis = pas de propagation dans le réseau interne. Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas Oui cela peut être fastidieux de maintenir la correspondance entre AD interne et compte locaux sur le SharePoint MAIS il existe des outils de synchronisation ET la sécurité a un prix
Solution #5 Mettre en place un AD dans la DMZ dont le SharePoint est membre et appliquer la même recette que pour #4. L'AD offre l'avantage être plus facilement "synchronizable" qua la SAM database locale
Solution #6 Mettre en place un AD dans la DMZ dont le SharePoint est membre et établir un trust UNIDIRECTIONEL entre votre AD DMZ et l'AD interne Ouvrir les ports nécessaires aux trusts quasi idem à solution #1 (voir http://support.microsoft.com/kb/179442/fr) Ouvrir le port 80 en inbound, optionnellement le port 25 en outbound -> de nouveau, on abaisse le niveau de sécurité, pas autant que dans les solutions précédente mais...
> Quels ports ais-je oublié et qu'en est -il de la fiabilité de cette > bidouille RPC en terme de compatibilité avec tout le tralala AD compatible > (GPO,FRS,services divers comme WSUS, WSS, cluster server, etc.) Tous ces services ou technologies Windows requièrent d'ouvrir des port ou des destination additionnelle sur le firewall et donc, des problème de compatibilité potentiels. Pense également à votre "pauvre" firewall qui va souffrir de toutes ces connections. Exemple un firewall placé entre un SharePoint et sa DB SQL sera vite sur les genoux sir ce SharePoint est fortement utilisé. Le problème ne réside pas dans la bande passante mais bien dans le nombre de connections
Bonne journée quand-même.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Lognoul, Marc \(Private\)
Bonjour,
Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas " ?
Etant donnée que les comptes et mot de passe sont identiques entre ADD et la SAM locale, si SharePoint est compromis, cela veut donc dire que ces mots de passe le sont également. Dans ce cas, il est préférable de forcer un changement de tous les mot de passe utilisateur dans votre AD, pas soucis de sécurité.
Dernière chose, quelles solutions existent pour synchroniser SAM et AD ?
Il existe plusieurs outil, don un composant MS: http://www.microsoft.com/downloads/details.aspx?FamilyIDÀ964F2E-FA9F-4FC7-AC13-C43928EFEE9D&displaylang=en au dessus duquel il faut bâtir de l'automatisation ou du code.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Bonjour,
Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes
de
votre AD interne dans ce cas " ?
Etant donnée que les comptes et mot de passe sont identiques entre ADD et
la SAM locale, si SharePoint est compromis, cela veut donc dire que ces mots
de passe le sont également. Dans ce cas, il est préférable de forcer un
changement de tous les mot de passe utilisateur dans votre AD, pas soucis de
sécurité.
Dernière chose, quelles solutions existent pour synchroniser SAM et AD ?
Il existe plusieurs outil, don un composant MS:
http://www.microsoft.com/downloads/details.aspx?FamilyIDÀ964F2E-FA9F-4FC7-AC13-C43928EFEE9D&displaylang=en
au dessus duquel il faut bâtir de l'automatisation ou du code.
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
Sinon, que veut tu dire par "Veillez à forcer un reste des mots de passes de votre AD interne dans ce cas " ?
Etant donnée que les comptes et mot de passe sont identiques entre ADD et la SAM locale, si SharePoint est compromis, cela veut donc dire que ces mots de passe le sont également. Dans ce cas, il est préférable de forcer un changement de tous les mot de passe utilisateur dans votre AD, pas soucis de sécurité.
Dernière chose, quelles solutions existent pour synchroniser SAM et AD ?
Il existe plusieurs outil, don un composant MS: http://www.microsoft.com/downloads/details.aspx?FamilyIDÀ964F2E-FA9F-4FC7-AC13-C43928EFEE9D&displaylang=en au dessus duquel il faut bâtir de l'automatisation ou du code.
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
