Need service network access...but no domain

Question

Need service network access...but no domain

lakusha

SSCommitted

Points: 1857
More actions
August 18, 2004 at 9:40 am

#85161

Hi all,
I have to setup a sql box at a client that doesn't have a domain and won't have one. He's got an LDAP server (Novell) and lots of linux & macs. I'm not familiar with Novell.
The SQL Server service needs networks access. I usually run the service with a domain account but since there is no domain I can only run SQL Service under a local user account.
Local user accounts don't have network access... so I'm stuck. Does anybody know a workaround for this?
regards,
eric

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

K. Brian Kelley SSC Guru Points: 114562 More actions · Answer 1

What is it needing to access on the network? Perhaps if we go at it from that direction, we might be able to come up with something workable. Any of the Linux servers running Samba?

K. Brian Kelley
@kbriankelley

lakusha SSCommitted Points: 1857 More actions · Answer 2

Hello Brian,

a) There are a few SQL jobs doing a lot of file IO on other servers using sp_OA procedures. It's working very well and it was done this way while waiting for SQL 2005 with CLR (still at least a year away for production purposes but I do have the beta 2 in hand ).

b) They do have Samba. They planned to map NT users in samba.

The problem is that NT services can't have network access when running under a local user account...and they don't have a domain. I might be missing an obvious solution since my experience with Samba & Novell is very limited. I do know they have a Novell LDAP server for authentication but no NT domain.

thanks

eric

K. Brian Kelley SSC Guru Points: 114562 More actions · Answer 3

If you have local accounts on both sides with matching passwords, pass-through authentication should work. Are they doing anything special to make the sp_OA procedures work in the other cases?

K. Brian Kelley
@kbriankelley

lakusha SSCommitted Points: 1857 More actions · Answer 4

Ooops. Strike the above. I just made another test. It does not work if the SQL server is part of a domain but it seems to work if it's only part of a workgroup.

Why is it that we always resolve impossible problems when there is nobody around but always end up asking for help on easy ones?

Thanks for taking the time to answer!

Have a nice day,,

eric

Jim Barker SSC Rookie Points: 29 More actions · Answer 5

Have the Novell admin create a user (e.g. NovellUser). Install the Gateway Service for NetWare on the Sql Box. This isn't the full Novell client. Just enough to give you access to the Novell servers. Create a login script to give the NovellUser to the Novell folders. Give the NovellUser Administrator rights on the box.

Make sure that all jobs are running under the NovellUser's account.

If you reboot, I've experienced that sometimes the NovellUser has to be the first user to log into the box and can only be done directly on the console or via timbuktu or pcAnywhere, otherwise the jobs don't have the correct permissions because the login script didn't run properly.

Regards,

Jim

Mitch Miller SSC Eights! Points: 829 More actions · Answer 6

Your statement that "local user accounts don't have network access" is incorrect. Services running as SYSTEM do not have network access, but local accounts do. Someone already mentioned passthrough security; works great. The target of your connection needs to have the same local user account with the same password, and your service will then be able to connect to that remote device.

NOTE: SQL Server and SQL Server Agent can each use different service accounts. Make sure you create the appropriate local user account on the remote device (i.e. SQL Server Agent if you're running scheduled jobs).

We do this all the time. I have a scheduled job which connects to a remote server, queries the directory content, then processes all the files on that remote server, gathering information out of each of the files, ultimately loading the data into a table on the SQL server.

-- Mitch

--Mitch