نوشته اصلی توسط
pardazande
1- دوستان عزیز علی آقا و M__K__M راستش چند وقتی هست من درگیر این موضوع بودم که آیزا واقعا باید به دومین join بشه یا نشه ؟؟ کدومش از لحاظ امنیتی بهتره ؟؟
شاید من نخوام یوزرهامو از طریق اکتیو بخونم. من یورهام کمه و مثل بعضی دوستان 200 یا 300 یا بیشتر یوزر ندارم . نهایتا بشه 60 تا یوزر همزمان و میتونم به صورت دستی واردشون کنم
ممنون میشم از شما که توی این بحث هم یه کمکی بکنید که آیزا عضو دومین باشه یا نه ؟؟؟
2- (Ezilator-جداکننده) که یکی از دوستان معرفی کرده دقیقا چکار میکنه ؟؟؟
ممنون از همه دوستانی که برای پاسخ به این تاپیک وقت میذارن
امیدوارم مفید واقع بشه:
Understanding Deployment Scenarios with ISA Domain Members and
ISA Workgroup Members
Installing ISA as a domain member is more common in smaller organizations that require
greater simplicity and administrative flexibility. One of the main reasons for this is that
these smaller organizations often deploy ISA as the main, edge-facing firewall for their
networks. When ISA is deployed in this fashion, the reasons against domain membership
become lessened because the server itself is directly exposed to network resources, and
even if it were to be compromised, making it a domain member versus a nondomain
member would not help things greatly.
One of the more common ISA deployment scenarios, on the other hand, involves ISA
being set up as a unihomed (single NIC) server in the DMZ of an existing firewall. In
nearly all these cases, the ISA server is not made a domain member because domain
membership would require the server to open additional ports on the edge-facing firewall.
In this situation, if the ISA server were to be compromised, there would be functional
advantages to keeping the server out of the domain.
A third deployment scenario in use in certain organizations is the creation of a separate
Active Directory forest, of which the ISA server is a member. This forest would be configured
with a one-way trust from the main organizational forest, allowing ISA to perform
domain-related activities without posing a threat to the internal domain accounts.
Functional Limitations of Workgroup Membership
. Local accounts used for administration—Because ISA is not installed in the
domain, local server accounts must be used for administration. On multiple servers,
this requires setting up multiple accounts and maintaining multiple passwords. In
addition, when remotely administering multiple servers, each server requires reauthenticating
through the console each time it is accessed.
. RADIUS or SecurID used for authentication—Because domain authentication is
not available, the ISA server must rely on RADIUS or SecurID authentication to be
used to properly authenticate users. Because an Active Directory deployment can
install the Internet Authentication Service (IAS) to provide RADIUS support, it is
possible to leverage this to allow authentication of domain accounts through
RADIUS on an ISA server that is not a domain member
. Firewall client use disabled—The one functional limitation that cannot be overcome
in a workgroup membership scenario is the fact that the full-blown ISA client
cannot be used. In reality, use of the full Firewall client, which provides advanced
firewall connection rules and user-granular access control, is not widespread, so this
may not factor into the equation. Because the SecureNAT client is supported, this
minimizes the effects of this limitation. SecureNAT clients are essentially any client
on the network (including those on the Internet) that can connect to the server and
does not require any special client software to be installed..
10سپاس
LinkBack URL
About LinkBacks
