Re: Replication for non-trusted domains through VPN can only allow push subscription.
From: Joe Mine (huytuanattpgdotcomdotau)
Date: 03/25/04
- Next message: Marnus: "User DBO Cannot exec sp_OA*"
- Previous message: Stephen Strong: "RE: Lost sa Password"
- In reply to: Joe Mine: "Re: Replication for non-trusted domains through VPN can only allow push subscription."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 25 Mar 2004 13:37:30 +1100
Is that the reason why there's an option to access the initial snapshot
folder using FTP...
To avoid the permission problem....
Is it easier to use FTP to access the initial snapshot folder than using
pass-through account???
And how do I solve this problem of Distrib.exe??? --- "The other problem is
that the distrib.exe (which is the heart of the
> > Distribution Agent) has its own authentication mechanism built in. The
> > Publisher, Distributor, and Subscriber talk to each other using RPC
which
> is
> > largely unauthenticated. The Distrib.exe is what handles the
> authentication."""
"Joe Mine" <huytuanattpgdotcomdotau> wrote in message
news:#zCTPcUEEHA.3784@TK2MSFTNGP10.phx.gbl...
> Thanks Hilary,
> It was a great help. You're right it falls into one
of
> the three category
> {{{{2) using untrusted domains where you are have problems mapping a drive
> to
> the repldata share on the publisher because the SQL Server Agent account
on
> the Subscriber cannot be give rights to access the admin share (by default
> \\PublisherServerName\C$\Program Files\Microsoft SQL
Server\MSSQL\Repldata).
> Your problem is complicated because your two servers are PDC's which do
not
> support adding accounts to the local administrator group and does not
> support passthrough authentication.}}}
>
> I used to have the two SQL Servers on two PDC, but they are now both on
> Application Server(without Active Directory) that allows local accounts
and
> pass-through accounts to prevent the Windows Domain Account problem.
> And still I can only create the push subscription but not pull
> subscriptions(in fact I haven't event register SQL11Server on
> HOT\SQL22Server as yet).
> What are the steps to setup and verify the pull subscription that I must
> take??? Thanks.
>
>
>
>
>
> "Hilary Cotter" <hilaryk@att.net> wrote in message
> news:#mdxoaIEEHA.3344@tk2msftngp13.phx.gbl...
> > is the replsa account in the system administrators role in both servers?
> >
> > The security mechaism employed with replication is rather difficult to
> > understand.
> >
> > There are two modes - windows authentication and SQL Server Standard
> > Security. You should always be using Windows Authentication unless you
> fall
> > into one of 3 categories:
> >
> > 1) replicating over the internet when the RPC calls necessary to map
> drives
> > are typically blocked at the firewall
> > 2) using untrusted domains where you are have problems mapping a drive
to
> > the repldata share on the publisher because the SQL Server Agent account
> on
> > the Subscriber cannot be give rights to access the admin share (by
default
> > \\PublisherServerName\C$\Program Files\Microsoft SQL
> Server\MSSQL\Repldata).
> > Your problem is complicated because your two servers are PDC's which do
> not
> > support adding accounts to the local administrator group and does not
> > support passthrough authentication.
> > 3) in workgroups where the member servers/workstations can support a
> limited
> > number of connections (5 on a workstation, 10 on a server).
> >
> > If you are using a Push Subscription you don't have any problem as the
> > Publisher will access the admin share \\PublisherServerName\C$\Program
> > Files\Microsoft SQL Server\MSSQL\Repldata. It is when you are using a
pull
> > Subscription, that you have the problem as in the three cases above the
> > Distribution Agent on the subscriber can't access the admin share.
> >
> > Accessing the Snapshot Share is only half the problem though.
> >
> > The other problem is that the distrib.exe (which is the heart of the
> > Distribution Agent) has its own authentication mechanism built in. The
> > Publisher, Distributor, and Subscriber talk to each other using RPC
which
> is
> > largely unauthenticated. The Distrib.exe is what handles the
> authentication.
> > It can use Windows Authentication or SQL Server Authentication.
> >
> > In the above 3 categories the Distrib.exe will not be able to use
Windows
> > Authentication on the subscriber if you are using a pull subscription.
So
> > you must use SQL Server Standard Security.
> >
> > There is one more catch with using SQL Server Standard Security in a
Pull
> > Subscription. The account that you use in the Pull Subscription must be
> part
> > of the PAL on the Publisher. To do this right click on your publication,
> > select properties, and then publication access list. Is the replsa
account
> > in the PAL? If not add it. If it is not on your publisher, add it to the
> > Publisher with the same password and make it a dbo on the publication
> > database.
> >
> > Getting back to your problem
> >
> > On your Subscriber you can't seem to register your Publisher. This means
> one
> > of two things. The accounts are not synchronized, ie not in the same
role
> on
> > both servers, and not having the same password.
> >
> > You can't connect to the correct server, ie your Publisher. Check the
> Server
> > Network Utility and make sure you have a correct alias set up using the
IP
> > address of the Publisher and its port, probably 1433.
> >
> > Can you ping the Publisher from the Subscriber? Can you ping by IP
address
> > and hostname? what happens if you do a ping -a IPAddress? do you get the
> > same host name returned?
> >
> > Check for the existence of a hosts file on your Subscriber
> > (C:\windows\system32\drivers\etc or C:\winnt\system32\drivers\etc) with
> > invalid entries in.
> >
> >
> >
> > "Joe Mine" <huytuanattpgdotcomdotau> wrote in message
> > news:udidrQCEEHA.3344@tk2msftngp13.phx.gbl...
> > > The current setup:
> > > -2 different non-trusted domains(NARC and HOT).
> > > -The connection is VPN and NARC domain has the VPN server.
> > > -2 SQL server are installed upon 2 Application Server in each
> > > domains(SQL11Server & SQL22Server).
> > > -In each domain SQL server/agent starts up with a common local
> > pass-through
> > > account (.\SQLAdmin)
> > > -Common SQL Server authentication account(repsa) in both SQL Servers
to
> > > replicate using SQL authentication.
> > > -Have create alias for SQL Servers in each domain.
> > > -Have setup SQL connection account to be (repsa)
> > >
> > > At the moment with the current setup I am able to create a push
> > subscription
> > > from the NARC\SQL11Server into HOT\SQL22Server and they
replicate/worked
> > > fine through vpn even though being non-trusted. I can register
> SQL22Server
> > > in the NARC\SQL11Server enterprise manager.
> > > But the problem is in the HOT\SQL22Server enterprise manager I cannot
> > > register the SQL11Server and cannot proceed to create the pull
> > subscription.
> > > Everytime I try to register the SQL11Server in HOT\SQL22Server
> enterprise
> > > manager it would turn up with error( Login failed for user 'repsa').
If
> I
> > > can't register SQL11Server in the enterprise manager I cannot do
> anything
> > > else. What is the problem that prevents SQL11Server registration in
> > > enterprise manager and how can it be fix so that I could create pull
> > > subscription????? Thanks.
> > >
> > >
> > >
> >
> >
>
>
- Next message: Marnus: "User DBO Cannot exec sp_OA*"
- Previous message: Stephen Strong: "RE: Lost sa Password"
- In reply to: Joe Mine: "Re: Replication for non-trusted domains through VPN can only allow push subscription."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
