Re: RPC - ImportBegin() / ImportNext()
From: Mathew Bosher (MathewBosher_at_discussions.microsoft.com)
Date: 10/01/04
- Next message: BELUCHIN: "Re: Conditional Accept and Overlapped I/O Question"
- Previous message: Ninov: "HOSTS file problem"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 1 Oct 2004 01:55:02 -0700
Hello Greg,
Problem now understood. It turned out that when the client first installed
their domain controller, an instance of our service was run by a user with AD
admin rights and the mpserver container was added.
Removing this container and ensuring the service is run by users whose
domain account does not have right access to the System\RpcServices container
has resolved the situation.
Your input was invaluable, many thanks.
Mathew.
"Greg Kapoustin [MSFT]" wrote:
> I am a little bit confused by your description of events. Specifically, the
> following sentence was confusing:
>
> > Our ImportBegin/ImportNext calls work when we use "/.:/mpserver" as a
> > starting point but theirs only works if they search the whole endpoint
> > mapper
> > using null.
>
> If you use the locator and the RpcNs* APIs, the endpoint mapper should not
> be in the picture as you are using it for the endpoint resolution.
>
> If the locator service has trouble accessing the AD on start-up, it will run
> in NT4 compatibility mode without using AD as storage. This may be
> happening in your case. You should investigate the cause of ADSI API
> failures you see in the sniff, since running in NT4 mode is much less
> secure.
>
> Greg
>
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Mathew Bosher" <MathewBosher@discussions.microsoft.com> wrote in message
> news:B94848C0-67E4-4C67-946C-F3F2F4AD0296@microsoft.com...
> >I have to add to the previous because it has now got more complicated.
> >
> > Our AddRequests fail when we are adding a container called "mpserver".
> > Their
> > active directory already has this container, but their AddRequest fails
> > for
> > the actual server entry being added to the "mpserver" container.
> >
> > Our ImportBegin/ImportNext calls work when we use "/.:/mpserver" as a
> > starting point but theirs only works if they search the whole endpoint
> > mapper
> > using null.
> >
> > So what is going on? If an active directory add fails, does some local
> > database get an entry instead. Ours fails at the "mpserver" stage and our
> > client search works at the "mpserver" level, theirs fails later and needs
> > the
> > "whole" search which is as though the server entry has been added locally
> > at
> > the top level. There is a consistency here but am I right?
> >
> > Could you point me at what happens locally.
> >
> > "Mathew Bosher" wrote:
> >
> >> We have now had a look at the LDAP traffic and the results are somewhat
> >> interesting.
> >>
> >> Where the server/client RPC communications work, the server's LDAP
> >> AddRequest, to the RpcService.System container, is failing with an
> >> "insufficient access right" error. As a result the client's subsequent
> >> LDAP
> >> SearchRequest also fails because the entry isn't there. This is where the
> >> client does retrieve the endpoint via the RpcNsImportNext() call.
> >>
> >> Where the server/client communications don't work, the AddRequest and
> >> SearchRequest both work. This is where the client does not retrieve the
> >> endpoint via the RpcNsImportNext() call.
> >>
> >> I still need to experiment with the code a little more but I would like a
> >> pointer regarding a user's access rights to the the active directory.
> >> What
> >> determines the user's write access to the directory or parts thereof? Are
> >> there ACLs or something that can be looked at? Sorry but this isn't my
> >> area.
> >>
> >> Keep it coming Greg because your comments have helped enormously.
> >>
> >> Mathew.
> >>
> >> "Greg Kapoustin [MSFT]" wrote:
> >>
> >> > You may be able to get a handle on what's going on by taking a network
> >> > sniff
> >> > of the success case (on your system) and the failure case (on the
> >> > customer
> >> > system) and comparing the two sniffs. In W2K+ domains, RPC Locator
> >> > uses AD
> >> > as the store and the locator service just acts as a wrapper around the
> >> > AD,
> >> > so the network sniff should show what's going on.
> >> >
> >> > This is also the reason why locator adds little value - you can just
> >> > use the
> >> > ADSI APIs directly to accomplish the same tasks.
> >> >
> >> > Thanks, Greg
> >> >
> >> > --
> >> > This posting is provided "AS IS" with no warranties, and confers no
> >> > rights.
> >> >
> >> >
> >> > "Mathew Bosher" <Mathew Bosher@discussions.microsoft.com> wrote in
> >> > message
> >> > news:29AD3C14-FF19-4A62-9475-F4F76F7B04DF@microsoft.com...
> >> > > Hello Greg,
> >> > >
> >> > > This is a "legacy" application that has worked very successfully for
> >> > > many
> >> > > years therefore there is a general reluctance to consider alternative
> >> > > methods.
> >> > >
> >> > > I have written a test console program for the ImportBegin(),
> >> > > ImportNext()
> >> > > and have found that when the ImportBegin(...EntryName = NULL...)
> >> > > rather
> >> > > than
> >> > > the exported BindingExport(...EntryName="/.:/mpserver"...), the
> >> > > client
> >> > > sees
> >> > > all the relevant named entries.
> >> > >
> >> > > So, on the customer's system, EntryName = NULL allows the client to
> >> > > see
> >> > > the
> >> > > entries, even when the endpoints themselves return "/.:/mpserver" to
> >> > > a
> >> > > BindingInqEntryName() call. Using EntryName = "/.:/mpserver" in the
> >> > > ImportBegin() returns nothing.
> >> > >
> >> > > On our system, the use of NULL or "/.:/mpserver" returns all the
> >> > > relevant
> >> > > entries.
> >> > >
> >> > > I don't really understand how this can happen when the service and
> >> > > client
> >> > > are running under the same domain account on the same machine.
> >> > >
> >> > > This makes me feel it is some domain/user/rpc configuration issue but
> >> > > I
> >> > > have
> >> > > little experience in these areas. Any advice would be appreciated.
> >> > >
> >> > > Mathew.
> >> > >
> >> > >
> >> > > "Greg Kapoustin [MSFT]" wrote:
> >> > >
> >> > >> You should avoid using the RPC Locator service, auto handles, and
> >> > >> the
> >> > >> RpcNs*
> >> > >> APIs since they offer an antiquated architecture with few security
> >> > >> considerations. Is there a specific reason you are using this
> >> > >> service?
> >> > >> There should be superior alternatives.
> >> > >>
> >> > >> To answer your question, the error would indicate that no bindings
> >> > >> matching
> >> > >> the search parameters specified by RpcNsBindingImportBegin() have
> >> > >> been
> >> > >> found. Possibly RpcNsBindingExport() has exported different data
> >> > >> than
> >> > >> what's being looked for. You can debug the RpcNsBindingExport()
> >> > >> call on
> >> > >> the
> >> > >> server to verify that it is exporting the expected data.
> >> > >>
> >> > >> Greg
> >> > >>
> >> > >> --
> >> > >> This posting is provided "AS IS" with no warranties, and confers no
> >> > >> rights.
> >> > >>
> >> > >>
> >> > >> "Mathew Bosher" <Mathew Bosher@discussions.microsoft.com> wrote in
> >> > >> message
> >> > >> news:797D503D-453D-495E-8438-8C037AA51731@microsoft.com...
> >> > >> > This is my first question on this forum so I apologise in advance
> >> > >> > if my
> >> > >> > question has already been answered or is too vague.
> >> > >> >
> >> > >> > Are there any conditions under which a successful call to
> >> > >> > RpcNsBindingImportBegin() may be followed by an immediate 1806
> >> > >> > (NO_MORE_BINDINGS) return from RpcNsBindingImportNext()?
> >> > >> >
> >> > >> > The ncalrpc protocol is being used.
> >> > >> >
> >> > >> > Our service has worked fine for years on a variety of OS variants
> >> > >> > but,
> >> > >> > at
> >> > >> > one particular customer site, the above is happening even though
> >> > >> > rpcdump
> >> > >> > is
> >> > >> > showing the relevant endpoint.
> >> > >> >
> >> > >> > One possibly big hint, but not big enough for me, is that the
> >> > >> > client
> >> > >> > process
> >> > >> > connects to the server when the service has been installed using a
> >> > >> > local
> >> > >> > user
> >> > >> > account but the above behaviour is seen when installed and run
> >> > >> > using a
> >> > >> > domain
> >> > >> > account.
> >> > >> >
> >> > >> > Any help would be much appreciated.
> >> > >>
> >> > >>
> >> > >>
> >> >
> >> >
> >> >
>
>
>
- Next message: BELUCHIN: "Re: Conditional Accept and Overlapped I/O Question"
- Previous message: Ninov: "HOSTS file problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
