Re: NT Named Pipes

eek <vince_at_vmoy.demon.co.uk> wrote in article <879972951.7557.0.nnrp-07.9e9892a8_at_news.demon.co.uk>...
> Our organisation has a security policy based on NT domains. We
> have found that SQL*Net configured to use TCP/IP allows users to see
> databases on machines outside their domains and in contravention of any
> trust relationships.

That's how it should work as far as I know. It will not disable user John Doe's SQL*Net access to a NT server outside the domain John belongs to. NT domain security does not "interfere" at the IP level - it does not have firewall capabilities. What it does support is trusted client connections to the server, i.e. if John logon to NT domain HR and the services on NT servers in that domain is configured for trusted connections, John can logon to/use any of these services without having to specify another userid and password (as he has already been validated by NT's domain security). Of course, this will only work if the services that run on NT in that domain support NT's trusted users. If a service is running that does not support NT domain security, any user on any domain that have a valid userid and password can make use of that service.

> We switched the configuration to use Named Pipes and
> security was restored, but at a cost. The network performance over a WAN
> slowed by a factor of two and we found that Enterprise Manager was not
> supported using Named Pipes. Is there a product, NT add-on which will
 allow
> use to use SQL*Net configured with TCP/IP and which will support NT
 domain
> security? Is there a product like Enterprise Manager which can run over
> SQL*Net using Named Pipes( CA-Unicentre, BMC Patrol, Ecosystems)? Any
> feedback on the memtion products greatly appreciated.

Hmm.. Strange that named pipes work and not sockets. Maybe because of the "proprietary" implementation of pipes in the protocol stack enables the NT kernel to ensure that only pipes from trusted clients can be opened? To my knowledge this should not work. If the service does not support NT trusted users, it does not support it - irrespective of the underlaying protocol mechanism. And if it does support it, it should also work whether you're running ip, ipx, named pipes or whatever.

I know pipes is a bitch on a network - there are a lot of overheads (unnecessary poling and broadcasts). Question, when running SQL*Net across named pipes, does the user still need to logon with an Oracle userid and password, or is he automatically logged on using his trusted id and password? If the user still needs to logon with an Oracle userid and password, it defeats the purpose of having trusted connection IMHO.

I suggest to stick to sockets. The overhead of named pipes on a network does not justify the little gain (if any) in using NT trusted user security. I think that trusted users are actually a weak link in the security fence as anyone having access to a person's PC can logon into any NT service without having to know any userid or password for that service. And it's also not that difficult to crack the domain userid and password used by a Win95 PC.

regards,
Billy Received on Thu Nov 20 1997 - 00:00:00 CST