This may turn out to be an entirely different question (domain related) but I shall endeavour to explain the situation.
As a UK-based resller we have been required to dip our toes into the world of McAfee SaaS (having previosly worked almost exclusively with Firewall Enterprise, Web Gateway, Mail Gateway and EWS appliance solutions).
I've been tasked with looking at SaaS Email and a colleague has been given the SaaS Web product to work with.
Because my requirement came first, I created the SaaS portal account and registered the SaaS EMail and Web licenses against it. I then went ahead an configured the Email component. As I am using a lab enviroment with one of our test/demo domain names registered to the Exchange server, this was the domain I declared when going through the process of setting up SaaS Email. From that perspective everything seems to be going OK.
However, the reason why I am posting this query is the Web section is because it is the web-side that is proving slightly more problematic and I'm beginning to wonder if things may be getting themselves into a bit of a knot as a result.
For the sake of explanation, the registered primary domain against this SaaS account is reseller-demo.co.uk (it isn't, but that's what I'm going with here).
As far as web access is concerned, if the SaaS web access policy is defined by IP address (using our public NAT address) and my colleague configures a browser to point directly to SaaS on port 3128 that works OK. However, the scenario he needs to test for the prospective customer requires WDS. He has installed the WDS element on the network and it appears to be running. But, if he tries to browse via this service all he gets back is a message along the lines of:-
You must be authenticated to access this URL
What we are beginning to wonder is if this actually has anything to do with the fact that the Active Directory domain on our network isn't "reseller-demo.co.uk" (which is a domain used purely for e-mail), but "reseller.internal" (to use a similar comparison).
Could the problem therefore be that WDS is authenticating the user correctly, but the domain credentials bare no resemblence to the domain name registered within SaaS?
If so how does SaaS handle the difference between e-mail domains and authentication (AD) domains for web access?
The WDS Connector matches the associated email address (the mail attribute to distinquish from non-Exchange AD systems that would not have proxyAddresses attributes), with the matching user in the control console. This is all done behind the scenes based on the domain authentication taking place between the Domain Controller and the end user terminal. So, yes, if there isn't a straight across match of, for example:
Then authentication will fail.
Because of this, you may want to avoid domain-authenticated web protection schemes such as WDS Connector or the McAfee Client Proxy while testing, and use Explicit Authentication direct to the proxy. This will prompt for login every browser session, but will allow use of the demo domain without intereference from the Domain Controller.
Thanks Brad -
I will bring this to the attention of my colleague tomorrow and we can think on this.
Am I correct in thinking that based on what I've read on the knowledge base, if we wanted to register a new primary domain (to separate email from web access) to our SaaS account we will need to create a service request?
Before he left for the day, he told me his plan B tomorrow was to re-install WDS on the same network segment as the domain controller on which I'm testing the registered e-mail domain for SaaS Email, so by the sounds of it that will fix the problem. Though he could just as well authenticate manually for his initial tests. But at least this clears up the relationship between the user, WDS, and the domain controller. Thanks.
We own multiple domains, but as there are so few of us here I think if we were to register all of them and each user for each domain counts as a license (even though email@example.com, firstname.lastname@example.org and email@example.com are all the same physical person) we still wouldn't actually exceed our license.
Adding additional domains depends entirely on how that domain should work. There are two types of add-on domains that can be included with an account, and the distinction between the two often trips folks up. You an add additional primary domains to the account, and yes those have to be done through a Service Request or through your master-partner (if applicable). Primary domains are for situations where the domains must be managed separately: they have separeate users, separate servers, but should still be administered through the same account. Think of additional primary domains as "subsidiary" accounts: you still administer them directly from the Customer umbrella, but, they're a "separate" entity in terms of granular management. Alias domains, which can be added at any time by a Customer Administrator (there is a Edit Aliases button on the Domain Details page, which is accessible under Account Management > Domains, and selecting the domain that will be the host of the alias domains). These inheret everything from the Primary domain automatically and are not in any way separately managed. That would likely be the best option to go with.
As far as licenses, and I would recommend confirming with your Partner or Account Manager on this as the policy may or may not have changed without us in support knowing, but last I was informed licensing was still being done based on physical people and not user accounts. That's not to say that there should not be some correlation between user accounts and billed users, but we anticipate the occational non-physical person account.
Hope this helps.