Anonymous_User Absent Member.
Absent Member.
2025 views

Windows service can't connect after 4.91SP3

Hello everybody,

We have an application designed on top of Visual Foxpro and .Net and it
has a Windows service running on WinXP workstation. Service needs to
connect to Visual Foxpro database sitting on the NetWare volume.

I created local Windows account on this PC with username and password
matching NDS user and service starts perfectly fine. All current updates
are installed in XP, Novell Client is 4.91SP2, server is NW65SP6 with some
post SP6 updates. The NDS user has all rights in the database directory.

As soon as I install 4.91 SP3 client, the service can't start anymore with
the error "invalid path to the database". Workstation still can login and
browse to the database and has all rights there. If I reinstall SP2
client, it works again. Installing SP3 client - fails again - I did this
twice already on the test workstation.

I did put the post SP3 client updates (nwfs.sys) and also tried beta
nwsso.dll and nwgina.dll but no luck.

We have two locations (same NDS tree, different servers) with the exact
same problem, SP3 breaking the service logon.

Any ideas, anybody?

Thanks in advance,
Igor

Labels (1)
0 Likes
9 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

oigor.yah.o.o@com wrote:

> We have an application designed on top of Visual Foxpro and .Net and it
> has a Windows service running on WinXP workstation. Service needs to
> connect to Visual Foxpro database sitting on the NetWare volume.
>
> I created local Windows account on this PC with username and password
> matching NDS user and service starts perfectly fine. All current updates
> are installed in XP, Novell Client is 4.91SP2, server is NW65SP6 with some
> post SP6 updates. The NDS user has all rights in the database directory.
>
> As soon as I install 4.91 SP3 client, the service can't start anymore with
> the error "invalid path to the database". Workstation still can login and
> browse to the database and has all rights there. If I reinstall SP2
> client, it works again.


Achieving an eDirectory login from a service, without the service
having any Novell/eDirectory-aware code or making any explicit attempt
to login to Novell/eDirectory, is somewhat of a delicate balance to
begin with. I imagine there are a few easy ways to break it even on
4.91 SP2 and earlier, not withstanding that you're also seeing that
4.91 SP3 changes apparently broke it too.

The fact that the service is being started under its own Windows login
identity (rather than LocalSystem) is good. This means that when the
service does login to eDirectory / create NCP connections, they will
be private to the service and not shared with all the other services
that are also running as LocalSystem.

But if the service doesn't have any explicit code for connecting to
Novell/eDirectory, what you're depending upon is the "pass through
authentication" attempt that will be made when the service tries to
access a network resource.

e.g. Depending upon exactly the same behavior as logging in
Workstation Only as the user, and then typing "\\MyServer\SYS" into
the "Run" dialog and expecting Windows and the Novell Client to
authenticate you to eDirectory without seeing any interactive login
dialog. i.e. Take my Windows username ("MyUser"), append to it
whatever the Novell Client knows as the current default eDirectory
context ("MyUser.SomeContext") and try to login using that information
& Windows account password. Since "the current default context" isn't
a fixed/constant value, that's usually the brittle point of such an
approach, and a transparent login will not always occur.

In order to deterministically assert "this service needs to log into
eDirectory as identity X to do its job", there would need to be either
Novell-specific code on the service to login as identity X, or perhaps
at least a Windows WNetAddConnection3-type API call to attempt logging
into the eDirectory tree or server as identity X (and depend upon the
fact that Windows, in turn, will be calling some Novell-specific code
in response to this API).

A discussion of the Novell-specific code to be added appears in the
following thread among other places:
http://groups.google.com/group/microsoft.public.win2000.netware/browse_frm/thread/c5d4b401b206dae1/

Let me also just caveat that I'm not running any services that make an
eDirectory login attempt, under 4.91 SP3 or otherwise. So if there is
actually something truly broken on 4.91 SP3, I'm not aware of it. My
response is more from the perspective that "something broke on 4.91
SP3" is not the first thing that comes to mind for the failure
scenario described.

Alan Adams
alancrumbadams@drcrumb.com
(for email, remove the crumbs)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

Another approach you can look into would be to setup a CIFS share for that
path, on the Netware server. Theoretically that should never get "broken"
by a NW client. In fact computers without a NW client installed would still
be able to use your application as long as they had to correct credentials.

Daniel Blake
Milford Central School

>>> Alan Adams<alancrumbadams@drcrumb.com> 1/18/2007 8:30:05 AM >>>

oigor.yah.o.o@com wrote:

> We have an application designed on top of Visual Foxpro and .Net and it
> has a Windows service running on WinXP workstation. Service needs to
> connect to Visual Foxpro database sitting on the NetWare volume.
>
> I created local Windows account on this PC with username and password
> matching NDS user and service starts perfectly fine. All current updates
> are installed in XP, Novell Client is 4.91SP2, server is NW65SP6 with some


> post SP6 updates. The NDS user has all rights in the database directory.
>
> As soon as I install 4.91 SP3 client, the service can't start anymore with


> the error "invalid path to the database". Workstation still can login and


> browse to the database and has all rights there. If I reinstall SP2
> client, it works again.


Achieving an eDirectory login from a service, without the service
having any Novell/eDirectory-aware code or making any explicit attempt
to login to Novell/eDirectory, is somewhat of a delicate balance to
begin with. I imagine there are a few easy ways to break it even on
4.91 SP2 and earlier, not withstanding that you're also seeing that
4.91 SP3 changes apparently broke it too.

The fact that the service is being started under its own Windows login
identity (rather than LocalSystem) is good. This means that when the
service does login to eDirectory / create NCP connections, they will
be private to the service and not shared with all the other services
that are also running as LocalSystem.

But if the service doesn't have any explicit code for connecting to
Novell/eDirectory, what you're depending upon is the "pass through
authentication" attempt that will be made when the service tries to
access a network resource.

e.g. Depending upon exactly the same behavior as logging in
Workstation Only as the user, and then typing "\\MyServer\SYS" into
the "Run" dialog and expecting Windows and the Novell Client to
authenticate you to eDirectory without seeing any interactive login
dialog. i.e. Take my Windows username ("MyUser"), append to it
whatever the Novell Client knows as the current default eDirectory
context ("MyUser.SomeContext") and try to login using that information
& Windows account password. Since "the current default context" isn't
a fixed/constant value, that's usually the brittle point of such an
approach, and a transparent login will not always occur.

In order to deterministically assert "this service needs to log into
eDirectory as identity X to do its job", there would need to be either
Novell-specific code on the service to login as identity X, or perhaps
at least a Windows WNetAddConnection3-type API call to attempt logging
into the eDirectory tree or server as identity X (and depend upon the
fact that Windows, in turn, will be calling some Novell-specific code
in response to this API).

A discussion of the Novell-specific code to be added appears in the
following thread among other places:
http://groups.google.com/group/microsoft.public.win2000.netware/browse_frm/t
hread/c5d4b401b206dae1/

Let me also just caveat that I'm not running any services that make an
eDirectory login attempt, under 4.91 SP3 or otherwise. So if there is
actually something truly broken on 4.91 SP3, I'm not aware of it. My
response is more from the perspective that "something broke on 4.91
SP3" is not the first thing that comes to mind for the failure
scenario described.

Alan Adams
alancrumbadams@drcrumb.com
(for email, remove the crumbs)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Windows service can't connect after 4.91SP3

Thanks, but I opened the incident with Novell and will post the results if
anybody needs them actually.

At this time I took a trace from SP2 client and SP3 client and it shows
that SP2 clients logs in correctly when the service starts, but SP3 client
attaches computername to the username (like this - username.computername),
resulting in -601 (no such object) in NDS.

> Hello everybody,
>
> We have an application designed on top of Visual Foxpro and .Net and it
> has a Windows service running on WinXP workstation. Service needs to
> connect to Visual Foxpro database sitting on the NetWare volume.
>
> I created local Windows account on this PC with username and password
> matching NDS user and service starts perfectly fine. All current updates
> are installed in XP, Novell Client is 4.91SP2, server is NW65SP6 with

some
> post SP6 updates. The NDS user has all rights in the database directory.
>
> As soon as I install 4.91 SP3 client, the service can't start anymore

with
> the error "invalid path to the database". Workstation still can login

and
> browse to the database and has all rights there. If I reinstall SP2
> client, it works again. Installing SP3 client - fails again - I did this
> twice already on the test workstation.
>
> I did put the post SP3 client updates (nwfs.sys) and also tried beta
> nwsso.dll and nwgina.dll but no luck.
>
> We have two locations (same NDS tree, different servers) with the exact
> same problem, SP3 breaking the service logon.
>
> Any ideas, anybody?
>
> Thanks in advance,
> Igor
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

oigor.yah.o.o@com .. I'm having the same problem 😞
So did you get a fix for this, or an ETA for a fix ?

The credentials are being passed through correctly. I can verify by doing a
workstation only login as the local user account the service runs under,
then doing a start... run.. to the unc path in question \\server\volume, the
credentials arent passing through and a login dialog is presented, even
though I have a bindery context set


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

oigor.yah.o.o@com .. I'm having the same problem 😞
So did you get a fix for this, or an ETA for a fix ?

The credentials are being passed through correctly. I can verify by doing a
workstation only login as the local user account the service runs under,
then doing a start... run.. to the unc path in question \\server\volume, the
credentials arent passing through and a login dialog is presented, even
though I have a bindery context set



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

Of course I meant the credentials ARENT being passed though correctly.. doh


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3


Ok, it is another 2 months passed. Novell still has the incident open,
they confirmed it is a bug. They suggest workaround to use novnpnt.dll
from 4.91SP2 client for now (I tested it works). Or reinstall the whole
SP2 client instead of SP3.

No ETA of a fix. Or maybe SP4 will fix it, I did not try beta though.

Igor


--
oigor
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

hello igor,


did you get any news about this ??


/joachim

<oigor.yah.o.o@com> schrieb im Newsbeitrag
news:0vyrh.2558$Sz4.2537@prv-forum2.provo.novell.com...
> Hello everybody,
>
> We have an application designed on top of Visual Foxpro and .Net and it
> has a Windows service running on WinXP workstation. Service needs to
> connect to Visual Foxpro database sitting on the NetWare volume.
>
> I created local Windows account on this PC with username and password
> matching NDS user and service starts perfectly fine. All current updates
> are installed in XP, Novell Client is 4.91SP2, server is NW65SP6 with some
> post SP6 updates. The NDS user has all rights in the database directory.
>
> As soon as I install 4.91 SP3 client, the service can't start anymore with
> the error "invalid path to the database". Workstation still can login and
> browse to the database and has all rights there. If I reinstall SP2
> client, it works again. Installing SP3 client - fails again - I did this
> twice already on the test workstation.
>
> I did put the post SP3 client updates (nwfs.sys) and also tried beta
> nwsso.dll and nwgina.dll but no luck.
>
> We have two locations (same NDS tree, different servers) with the exact
> same problem, SP3 breaking the service logon.
>
> Any ideas, anybody?
>
> Thanks in advance,
> Igor
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows service can't connect after 4.91SP3

Hi,

achim wrote:
>
> hello igor,
>
> did you get any news about this ??


The bug is still open, so for the time being, it's the novnpnt.dll out
of SP2.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.