A "secure" Guest account for ISA server

[BOT House]

Humor me on this, please. I know it's a stupid question.

Given:

a)the Guest account has been renamed

b)the Guest account's password is blank

c)the only right the Guest account needs is "access this computer from the network", but it doesn't need file or print access

d)this is a Windows 2000 member server in an NT4 domain (AD to be implemented next year)

How would you go about "securing" the server?

I'm thinking explicit denies on various registry keys and system files.

The problem is this: management wants to deploy an interior anonymous proxy server, but they want to know who uses it to go where.
Probably 75% of the users will be from trusted domains. It is up to the untrusted domains as to how they will prevent "their" users
from using "our" proxy (yes, it's a political nightmare).

The only way around this that I can see (without an ISA everyone/everywhere anonymous rule, which is enforced before authentication)
is a Guest account with a blank password.

This worked well on Proxy 2.0 because it would log PROXYSERVER\UNTRUSTEDDOMAINUSER whenever someone used the Guest account. ISA
unfortunately logs ISASERVER\GUESTACCOUNT, but I can live with that.

The ISA server sits behind a PIX so it's not directly exposed to the Internet. It will support Web Proxy and Firewall clients, but
not SecureNAT clients.

REGARDLESS OF THE UNDENIABLE FACT THAT ENABLING "GUEST" WITH A BLANK PASSWORD IS A BAD IDEA, how would you go about locking it down
as much as possible but retaining ISA functionality?

 

[Steven L Umbach]

Assuming you need to use the guest account, which I don't know for sure since I am
not an ISA guru, you can replace users/everyone group on acls with the authenticated
users to places you do not want anonymous access as access will be denied. Also
disabling file and print sharing on the ISA server will go a long way to protect it
assuming of course it does not need to offer shares, but that will also disable the
use of Computer Management for remote management. Of course you could still use
Terminal Services to remotely manage the server in administration mode which would
only allow administrators to use it to access the computer and of course complex
passwords must be used. I would also add the guest account to deny logon localy user
right for that computer. --- Steve

Humor me on this, please. I know it's a stupid question.

Given:

a)the Guest account has been renamed

b)the Guest account's password is blank

c)the only right the Guest account needs is "access this computer from the

network", but it doesn't need file or print access

d)this is a Windows 2000 member server in an NT4 domain (AD to be implemented next year)

How would you go about "securing" the server?

I'm thinking explicit denies on various registry keys and system files.

The problem is this: management wants to deploy an interior anonymous proxy server,

but they want to know who uses it to go where.

Probably 75% of the users will be from trusted domains. It is up to the untrusted

domains as to how they will prevent "their" users

from using "our" proxy (yes, it's a political nightmare).

The only way around this that I can see (without an ISA everyone/everywhere

anonymous rule, which is enforced before authentication)

is a Guest account with a blank password.

This worked well on Proxy 2.0 because it would log PROXYSERVER\UNTRUSTEDDOMAINUSER

whenever someone used the Guest account. ISA

unfortunately logs ISASERVER\GUESTACCOUNT, but I can live with that.

The ISA server sits behind a PIX so it's not directly exposed to the Internet. It

will support Web Proxy and Firewall clients, but

not SecureNAT clients.

REGARDLESS OF THE UNDENIABLE FACT THAT ENABLING "GUEST" WITH A BLANK PASSWORD IS A

BAD IDEA, how would you go about locking it down

 

[Robert Moir]

Humor me on this, please. I know it's a stupid question.

Given:

a)the Guest account has been renamed

b)the Guest account's password is blank

c)the only right the Guest account needs is "access this computer
from the network", but it doesn't need file or print access

d)this is a Windows 2000 member server in an NT4 domain (AD to be
implemented next year)

How would you go about "securing" the server?

I'm thinking explicit denies on various registry keys and system
files.

The guest account has surprisingly little access anyway. If all you are
using it for is for "authenticating" anonymous proxy users, you could and
add it as an explicit deny to anything you were concerned about in the file
system or registry, without problems I should think.

The problem is this: management wants to deploy an interior anonymous
proxy server, but they want to know who uses it to go where. Probably
75% of the users will be from trusted domains. It is up to the
untrusted domains as to how they will prevent "their" users from
using "our" proxy (yes, it's a political nightmare).

I've got to ask, and I realise you probably already know this and i'm
totally not having a go at you, isn't deploying an anonymous proxy server
but wanting to know *who* uses it to go *where* a contradiction in terms?
Surely its either anonymous, Or, you want to know who uses it to go where?

I'm guessing you've been given a list of stuff to do by a manager who
doesn't understand the issues here, but it seems to me that with that set of
goals, someone somewhere is going to be disappointed with the outcomes?

--

 

[BOT House]

It definitely is a contradiction, but we are mandated to give everyone unrestricted Internet access. It's very much like a
"dot-edu" environment in that respect. However, if a department head asks for a report on a certain individual, we must produce it.
You can't do that if it's totally anonymous. So, we track the users we can and don't worry (much) about the users we can't. When
it's all anonymous, all you have is IP addresses to go by, which is unacceptable from a non-repudiation standpoint, especially in a
DHCP environment.

So, the people who are going to be disappointed are the managers in the untrusted domains. Hopefully they will be disappointed with
their own IT staff.

BTW, the policy "Additional restrictions for anonymous connections - no access without explicit anonymous permissions" worked
nicely. I am putting restrictions on the registry as they pop up, but it's looking good so far.

 

[N. Miller]

The problem is this: management wants to deploy an interior anonymous proxy server, but they want to know who uses it to go where.
Probably 75% of the users will be from trusted domains. It is up to the untrusted domains as to how they will prevent "their" users
from using "our" proxy (yes, it's a political nightmare).

This is a big problem. Your managers want to trust an "untrusted" domain to
prevent your proxy from being abused? Why don't they just issue blank checks
to the employees on payday? It is up to the trusted network to prevent
access by untrusted domains. Period. Otherwise there is no sense in even
trying to secure the proxies.

 

[BOT House]

This is a big problem. Your managers want to trust an "untrusted" domain to
prevent your proxy from being abused? Why don't they just issue blank checks
to the employees on payday? It is up to the trusted network to prevent
access by untrusted domains. Period. Otherwise there is no sense in even
trying to secure the proxies.

Um, we are not trying to secure the proxy. We are offering everyone unlimited Internet access whether we trust them or not and
whether their department heads like it or not. It is our mandate. It is a function we must perform.

That's not the problem. The problem is, for those users we CAN authenticate, how do we do that without a Guest account on ISA
server? Can't be done, unless you consider a person is authenticated by his/her IP address, which is nonsense.

And as far as the paychecks go, the Printers Union won't let us do that.