|
We had this
argument about an app that’s being built here. The WAN people who own
firewalls and such are of the general opinion Microsoft == Bad, Unix == Good.
So, this app uses some convoluted farmer engineered mechanism to authenticate
the user against AD. The app folks and the security folks were/are convinced
that someone is going to hack the app and totally trash AD. Their solution was
to put two GCs in a massively firewalled subnet & new AD site, which would
somehow alleviate the problem. This obviously doesn’t work, all it did
was f up replication. My argument to
this particular group was that Sharepoint isn’t getting hacked, OWA isn’t
getting hacked, and all sorts of other apps are fine, what’s so special
about yours. Anything that prompts a user for credentials and takes them to AD
is just as much a problem as the next, assuming the apps are all coded properly.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long I see the view point that everyone else
is talking about, but it seems kinda hard to keep AD from the internet. What do
you do for VPN access, OWA, portals that authenticate against AD, etc? Is
the solution for these things to create another username and password for all
of them? Generally speaking the whole point of AD is to reduce admin task. The other
holy grail that is all the buzz these days is SSO, is that just a CIO (shiny
things are cool) idea? That aside, wouldnt it be better to setup a *nix box that is
authenticating against AD and use SFTP for such a thing? Or heck, maybe there
is SFTP for windows? I guess that would require a client, but you could link to
one. Honestly I would like to keep this discussion going, but
maybe more on the topic of security in general. I value alot of peoples
opinions who take part in this group, and wouldnt mind opening my mind to ideas
or side effects that i may have not thought about. Just my two cents (or is mine only worth one) From:
[EMAIL PROTECTED] on behalf of joe The thing to keep in mind, is if ever the
machine is compromised, the attacker has the same access to resources that the
box has. So if the box can see the directory, so can the attacker. Also keep in
mind that if there is any method to push auth back to the main directory, the
D.O.S. possibility is there. Enumeration of accounts may or may not be there,
but probably is. Unless there is something non-domain
related front ending the whole thing I am not a big fan of anything that
touches a real production AD in an way being available from the internet
for the D.O.S. lockout issues alone. You throw something in front of it say a
securID auth or something like that. Otherwise, if they get a hold of your SAM
Name or somehow guess it, you have possible D.O.S. problems at least. How hard
is it for someone to get your SAM Name? I don't believe you can really front-end
normal ftp with any real protection, you are kind of hanging out there so my
preference would be to have it stand alone. This is just an opinion though. There are
probably people on the list that are violently opposed to what I am saying. I
am a "look for the worst case" kind of person by training though. I
build out with the maximum redundancy I can get away with and try to lock
things down to within an inch of everyone's life. On the other hand, I am often
not surprised by bad things happening and usually have it covered. There was
one case I was involved in where a local resource domain had its password
hashes cracked by one of the resource domains admins and he got maybe 50 or 60
passwords. One of the other admins of the resource domain involved had an
admin ID in a related account domain, he had the same password so his ID
was used to crack the account domain, this resulted in the guy getting another
40,000 or so accounts and passwords. One of the IDs in the account domain was
an account for an Exchange admin, his password was the same in the Exchange
domain so the Exchange domain got cracked and about 40 or 50 more IDs were
compromised including the Exchange Admin ID which was a bear under Exchange
5.5. Several of my domains were attached to that Exchange domain as
well and we had several of the people of the Exchange domain in our domain
but I am a big isolationist and different systems get different passwords and I
don't let people have rights in my environments unless they truly need them all
of the time, etc etc etc so there was no step for this person to jump to my domains
except as a normal user. However just the same, we forced the expiration of
some 200k userids over the course of the couple
of weeks so the cracker couldn't access user data of
someone silly enough to have synced their passwords on multiple accounts across
the environment instead of using trusts or having separate passwords for the
separate accounts. Security is risk management, you need to
judge how much risk there is, what the risk is, what the compensating controls
if any are, and then determine how open (aka insecure) you can be.
Open/insecure tends to be synonymous with ease of use. The less open you can
afford to be, the more difficult it will generally be to use the environment.
But if the risk justifies it, people need to deal with it. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Garrett Do you have a DMZ you can put the FTP
server into? This would allow the low security "Outside" interface to
reach the medium security DMZ interface and the DMZ interface could then
validate usernames via LDAP (AD) to the high security "Inside"
interface, right?
|
Title: Message
- RE: [ActiveDir] FTP Server In or Out Brian Desmond
- RE: [ActiveDir] FTP Server In or Out Douglas M. Long
- RE: [ActiveDir] FTP Server In or Out joe
- RE: [ActiveDir] FTP Server In or Out Noah Eiger
- RE: [ActiveDir] FTP Server In or Out Brian Desmond
