I'm just looking into the process of populating the SaaS Email environment with users/accounts using a pre-existing Active Directory service.
Reading through the "Directory Integration" section of the Accunt Management Administration Guide, it would appear there are two options when using LDAP - Email Domain or AD Domain. The guide suggests that if you only have a single domain, that "Email Domain" is the option to go for and if there are multiple alias addresses present for different domains the "AD Domain" option should be pursued.
It then goes on to explain there is also a Directory Services Connector which can be used for this purpose, but that this requires ePO to be up and running on the network.
Given the customer environment I will be shortly working on is known to use multiple e-mail domains and there's every chance that users won't necessarily just have alias addresses with the same e-mail domain (firstname.lastname@example.org, email@example.com, firstname.lastname@example.org), but may also have alias addresses belonging to one or more additional e-mail domains (email@example.com, firstname.lastname@example.org, email@example.com), I've concluded that AD Domain is the correct route to take.
However, when I select this as the Logical Structure option in Account Management -> Directory Integration -> Configuration, the system immediately seems to assume I will be Directory Services Connector.
As I know this customer is not a mainstream McAfee customer (they have Firewall Enterprise appliances, but ePO integration isn't a fundamental requirement) they do not currently have ePO deployed.
How can we acheive what I know the customer will need without being forced to install ePO and the Directory Services Connector?
Is it possible to create multiple EMail Domain entries for each domain name (primary or alias) registered to the customer's SaaS service?
Another question I have - with many AD environments using an 'internal' domain name, the user's primary e-mail address will often be associated with a different domain name. So to use the Bob Smith example his active directory domain address may well be bob.smith@acme_ad.local when his Internet e-mail address will be the aforementioned firstname.lastname@example.org. (and the domain registered to SaaS will be the acme.com one), how will SaaS handle the creation of user accounts from LDAP?
The AD Domain structure utilizes a "Push" method of syncronizing the data from Active Directory, so is only possible with the Directory Services Connector and ePO.
You can use the Email Domain option for multiple domains, it's just not quite as simple. For primary domains, Directory Integration must be set per-domain. For alias domains, those will be automatically inherited from the primary address. The only exception would be if there are alias usernames in addition to the alias domains (email@example.com and firstname.lastname@example.org), then you may need to ensure there is a proxy address entry for bsmith at the primary address as well.
As far as the .local addresses, those will be discarded. As long as an email address exists in proxyAddresses at the primary domain in the Control Console, the user will be created.
For alias domains, those will be automatically inherited from the primary address.
Do you mean by this if SaaS has been configured with a primary domain of "domaina@.com" and that has an alias domain of "domainb.com", an Email Domain import via LDAP from an Active Directory source will create a Primary User account within SaaS of email@example.com and an alias of firstname.lastname@example.org - or will this still rely on the presence of an additional email@example.com proxyAddress attribute against his AD account?
I ran a test and Sync after I posted my question and kind of got the idea that the ".local" address would be discarded automatically (because the "alias was not properly formatted", if I remember the message correctly?).
In your example, it will be the former. Domain alias accounts are automatically inherited from the primary username, so they don't neccisarily require a proxyAddresses entry, although one is recommended for congruency between the two systems (and so the mailbox can receive on both the alias and primary domains).
OK - (trust me I'm not being deliberately awkard - just trying to get everything straight in my head).
If an AD "pull" import results in user accounts being created with both primary and alias domain addresses:-
What happens if, in AD, Bob Smith's user account only has an e-mail address for domaina.com and someone tries to send a message to firstname.lastname@example.org?
Maybe I'm am mistaking the process of creating accounts within SaaS for the kind of LDAP recipient validation process found in some on-premise solutions (such as McAfee Email Gateway) where the system will process the RCPT TO part of the SMTP transaction and, if there isn't a positive result, the connection is dropped. What I'm seeing in the potential for the opposite problem to occur - where SaaS does believe that mail for email@example.com should be allowed but when it comes to sending that mail on to the mail server hosting the mailboxes for domainb.com it responds with "Bob who?..."
On that note, as I am based in the UK and it is gone 5pm on a Friday - I'm going home
Message was edited by: PhilM on 01/11/13 17:08:28 GMTMessage was edited by: PhilM on 01/11/13 17:08:49 GMT
As long as the message passes the filtering layers, McAfee will attempt to deliver the message, and assuming the recipient server is configured to bounce invalid errors intransit, we will issue an NDR based on the error we recieve.
The SaaS product can do something similar, assuming the User Creation mode is set to Explicit and configured to Deny or Silently Discard the message. But that will not prevent situations where the user has a domain alias entry that is automatically inherieted but the backend server is not configured to actually receive mail. The action taken will be what is described above.
The rule of thumb I recommend using when determining if the domain should be an alias or a primary (with the neccisary accounts cross-linked), is that if MOST of the users will receive email on both domains, then go with alias. If only a handful will, then it's best to treat the domain as a primary to prevent the situation I described above.
If only a handful will, then it's best to treat the domain as a primary to prevent the situation I described above.
Though, thinking on this over the weekend I assume that opting only for primary domains might be an issue.
I agree that if an organisation has multiple domains it is reasonable to assume that each user will have an address in each domain. Therefore, unless they wish to be extremely granular with their filtering it would be equally reasonable to have a single primary domain and list all of the others as aliases - so our friend Bob Smith would have a primary email address of firstname.lastname@example.org and aliases for domainb, domainc, etc...
If the customer chose to register each domain as a primary I am assuming that email@example.com and firstname.lastname@example.org would each take up a license within the SaaS environment and the customer could easily exceed their license count even though, in the real world, Bob is a single physical users.