the AP requests shouldn't come from the appserver - the auth requests would be from the target to their DC.
is the nat a 1-to-1 ? you can use a socks proxy at the remote sites to deal w/ that and any overlapping ip ranges.
Good morning Bill,
Let me clarify more the topology. Application servers will all be on DomainA and agents on DomainB. These domains are different forests with no trust and isolated between them. We are looking to use RBAC and create a compliance officer (domain user) authenticated in DomainA and a patching officer (domain user) authenticated in DomainB.
In order to create the patching officer shouldn't conf appserver (DomainA) be able to discover DomainB's kerberos service record?
1) For 1-to-1 NAT are you referring appserver to every agent (approx 600)? Wouldn't that mean I would have to allow agents to listen on a range of ports?
2) Could copying of metadata files (from patch and compliance analysis jobs) from DomainB to DomainA over a router be an issue due to the sheer size of them?
3) Since this is a distributed BSA scenario would the following constraint be valid: "BMC Server Automation Repeaters cannot be used with automation principals, because the repeater must contact the target agent without benefit of access to the BMC Server Automation database."
Would I be able to overcome this using an Advanced repeater?
There is no requirement for cross authentication between the domains. As Bill says the authentication is carried out at the agent level to it's local authentication services.
You can use NAT but that introduces DNS/name resolution difficulties. I would recommend SOCKS proxies if you can only connect to the managed servers via NAT.
You understand there is a difference between the AP and a bsa user login right? if i login to bsa as a domain user, when i talk to servers i'm not automatically going to be that user on the target. so what do you need to do here ?
- authenticate BSA users against active directory?
if that's the case then the appserver needs to talk to the KDCs for each realm/domain on 88/tcp
- perform actions against a target as a certain domain user?
if this is the case there's no requirement that the appserver needs to talk to the kdc for the realm/domain
so if it's the former case, why do you want to use a user login in domainB here? that's the login to bsa. what's the point of having it in domainB ?
1 - 1-to-1 nat means that ever target server would have a unique IP address accessible from the appserver. or how is this nat setup ? typically to deal w/ NAT you would use a socks proxy where the appserver can communicate w/ the proxy, and the proxy w/ the target agents.
2 - maybe. depends on the router and whatever other network infrastructure is involved.
3 - repeaters are not used for patch analysis. the ars does not support using an AP either.
Thanks for all the answers, I have a better understanding now.
So to recap conectivity wise I need to allow at agent zone incoming connections from appserver zone at port 1080 through a 1-to-1 NAT between appservers and socks proxy server (or is it just between the job and socks proxy server).
Is it the same for the reverse link (proxy answering back on port 1080 to both appservers or just job or config?)
Can I use the offline patch downloader to download the patches directly to a file server on agent zone and not make use of a repeater which would mean to copy once every payload over the WAN?
1 - the appservers (all of them) need to communicate w/ the socks proxy on whatever port it runs on. the proxy will need to communicate w/ the target agents on 4750.
2 - the firewalls should be stateful and the agent or proxy never initiate a connection to the appserver so you don't create rules allowing that.
3 - yes, you could, and you would need to use the 'AGENT_MOUNT' url type and your agents would need to be able to mount the share w/ the patches via nfs (unix) or smb (windows). but you would still need a catalog stored centrally (you don't want the CUJ to run over the wan). so what you can do here is setup a file deploy job or some other sync job that would copy the patches from a central location to the remote location on a scheduled basis and then during the deploy only the remote location is referenced.
May I clarify a couple more points on this:
Can I have a central installation and many remote sites behind NAT or it will need to be central installation to one site behind NAT and the rest of the sites should be visible (by VPN etc) by the first remote site? In other words can one installation support multiple socks proxy servers?
Can I use the UAI through a socks proxy?
The file deploy or rsync job is it a BSA functionality through the proxy or you are referring to another method (which would also require additional connectivity) ?
Thanks again for all the support
1 - yes - you can have multiple customer environments behind different socks proxies all managed by the same bsa install. you can also have servers behind socks and not behind socks in the same env.
2 yes - look at the 'what's new' here: https://docs.bmc.com/docs/display/public/bsa86/8.6.00+enhancements?
3 - if you use a file deploy job then yes it will use the socks proxy.