"Michael" <Michael@discussions.microsoft.com> wrote in message
news:38AA0546-61A9-4B8A-B68E-3568F18B3F66@microsoft.com...
>
> Are you sure about this ?
> It seems to be a common conception on the net that allowing AD
> authentication from the DMZ is a risky practice. It also forces you to
> allow
> SMB traffic, which I am realy not sure is a goot idea. For example, I
> guess
> someone could establish a null session from the DMZ on the DC in order to
> list the domains account and group (exemple).
>
> My question is : is there any way to have an application authenticate
> against AD but in a safe way.
>
ADFS, but right now that is mostly only for web applications/services
and implementing it is a bit resource intensive. It does however fully
isolate your AD internals from the external needing to use authentication
services based on your AD.
The problem will a trusting entity in the DMZ, whether that is a domain
trust or a machine trust (i.e. domain member), is that you will have needed
to define network traffic path between the trusting and the DCs of the
domain and of any potentially different domain's that might act as account
domain in the forest (note however that this can be reduced from all such
DCs by controlled DNS visibility).
Obviously, if the trusting becomes compromised then the network path
is available, and the native capabilities of a trusting partner are fully
available (list domains, accounts of forest, map forest via DNS, etc.).
I believe Slav was intending to state that having the path from the DMZ
defined is not a problem provided that the end-point machines are not
compromised. I would have not said "not a risk" but maybe "not a
vulnerability" or "a risk only to extent that the trusting is at risk of
being compromised". (on second thought, you said it was a Sharepoint
server, so anyone that could find a window to inject web app code, or
get granted web authorship, could potentially remotely over tcp 80
obtain any info that the trust provides)
> I heard about ADAM but I could not exactly figure it out. I was hoping
> that
> somebody here could easily tell me.
>
ADAM (note that is the old name) could be part of a solution, but
it is not in itself going to isolate your DMZ machine and break the
risks for the internal unless coupled with some means for it to use
the internal identity/authentication other than domain membership
or trust (i.e. ADFS).
Roger
> "S. Pidgorny <MVP>" wrote:
>
>> Open ports aren't a security risk (let alone a breach). If you know
>> what's
>> using them, and conections are properly authenticated, there is no
>> problem.
>>
>> --
>> Svyatoslav Pidgorny, MS MVP - Security, MCSE
>> -= F1 is the key =-
>>
>> * http://sl.mvps.org * http://msmvps.com/blogs/sp *
>>
>> "Michael" <Michael@discussions.microsoft.com> wrote in message
>> news:9CF2CD88-6E77-4173-AA22-D7F8654C2F72@microsoft.com...
>> >I recently faced a situation where a sharepoint was part of a domain
>> >inside
>> >a
>> > DMZ. There was a separate domain, inside the corporate network.
>> >
>> > The element I was concerned with was the following : the DMZ domain
>> > trusted
>> > the internal domain and the sharepoint allowed users from the inside to
>> > access some ressources.
>> >
>> > My assumption was that this was a potential security breach since
>> > multiples
>> > ports needed to be open between the inside and the DMZ, and that this
>> > architecture could allow an attacker to eventualy get to the inside
>> > from
>> > the
>> > DMZ.
>> >
>> > I am just curious about what would be the 'best practices' regarding
>> > that
>> > situation. Of course you can have just two domains, but obviously the
>> > people
>> > on the corporate network need to share ressources with partners
>> > outside.
>> >
>> > What is the recommended way to deal with such a situation ? Is there
>> > any
>> > safe way of allowing internal users to simply authenticate on such a
>> > shared
>> > ressource with the outside ?
>>
>>
>>