This message was deleted.
# citrix-cloud
s
This message was deleted.
j
Exactly. Vnet or OnPrem cloud connector connectivity is only required if you would like ldaps / radius or any other OnPrem auth-source. When you’re using saml / oauth there is no need for an OnPrem connectivity.
m
If I chose "Cloud Connector" vs VNet peering as my connectivity method during the setup, how does the ADC instances get back to my cloud connectors without a VPN?
j
There is a mapping between OnPrem backend subnets configured in an expression and the Cloud Connector is acting as a forwarder. See Citrix DaaS - Adaptive Authentication - Julian Jakob for technical details
m
If I specify Cloud Connectors, do I need to add authentication policies to nFactor? I see the mapping, but I can't figure out how entering credentials to a hosted NetScaler Gateway get back to the Cloud Connectors. I can understand how the Cloud Connectors may forward information egress to the ADCs.
j
Yes, you have to configure the Adaptive Auth NetScaler like a "normal" NetScaler with all kind of authentication policies bound to the pre-deployed AAA vServer
m
That's what I'm hung up on. With the cloud connector connectivity type, I think my only option is SAML since the ADC has no direct contact to AD and RADIUS.
j
Isn't there an OnPrem Domain Controller in the same Resource Location / DataCenter where your Cloud Connectors are?
m
Yes. You're saying I can configure LDAP and RADIUS policies as if the ADC is in the datacenter?
j
Exactly. I would recommend to take 10 minutes and read my post, I think than you're getting the "Ahhha" effect 😉
m
Your blog has been super helpful to this point! Citrix released their own POC guide, which was a lot like yours, but again stopped short of configuring nFactor to show you can plug private IP addresses in. I f I understand you right, the Cloud Connector acts as some sort of proxy for the ADC. I'll have to give configuring nFactor a try ignoring these things are somewhere else on the internet and see what happens.
In testing a simple LDAP Server, I test the network connectivity and get "Server 'x.x.x.x' is reachable. Port '636/tcp' is open. Either 'x.x.x.x' is not an LDAP server or port '636' is not a LDAP port. My cloud connectors cannot communicate with the Adaptive Auth FQDN, which hopefully is the problem here.
👍 1
a
@Matt Sliva Yes Cloud Connector need to communicate with AA FQDN
m
I was able to successfully configure an LDAP action and test the binding. It blows my mind how the Adaptive Authentication NetScalers can tunnel back to the Cloud Connectors to proxy things like LDAP and RADIUS authentication requests. Does the tunnel also work for NTP?
a
NTP configuration should point to external public NTP servers, however, you will have to configure DNS if you want to use NTP names. DNS is also tunneled.
🤯 1
@Matt Sliva My bad, DNS does not need anything it's configured with Azure, so just NTP configuration
m
In a cloud connector connected scenario? if my internal ntp server was ntp.company.com, I figured I would need to create an A record on the Adaptive Auth NetScaler for it to resolve at the very least.
a
If you want to use your internal NTP server, you will need to add your internal DNS to the configuration on the NetScaler and then provide your internal NTP server.
👍 1