my client has created a group in Active Directory composed with members with an internal email address but also members with an external email address
One characteristic of this group, to avoid spamming, is that a person who wants to send an email to these people needs to be authenticated.
My client, using the publication functionality, would like to send webi reports to this group. However, only the people with an internal address receive the email.
It appears that BO does not authenticate, as required by AD… hence the reports not received by the “external members” of the group.
A few questions:
in the Adaptive job server / Destination / email, no User Name has been defined.
. * what is the “User Name by default” used by BO ?.
. * Is it possible that this “User Name by default” does not authenticate ?
. * Is there any documentation about the User Name option ? (what it does, what it requires…)
Or is there a way, in AD, to define exceptions to the “authentication required” option ? (yes, I know it’s the wrong forum for this question, but I’m sure you guys know that :o)
. * if so, what address should I put in the exception list ?
I assume that this is the same user that is running your Server Intelligence Agent. It functions this way for the File System destination.
Very possible, especially if you are using the System account to run your Server Intelligence Agent. It would also depend on what account you are using for this. In SAP KBA 1611420 - How to use a Gmail account for testing schedules to email delivery, it talks about using a Gmail account to authenticate to Gmail to use it as your SMTP server. This seems to indicate that the user would need to authenticate to the domain that is entered in your Domain Name field.
I haven’t found anything other than the above mentioned KBA.
We use a domain account to run our Server Intelligence Agent because we have a clustered environment and it needs to be able to write to the file server for the FileStore. This same domain account can log into our email domain so I assume this would be considered “authenticated”.
Assuming that you have a test environment, you can always test setting a User Name and then see what happens.
The question here is whether you can use an AD ID/password for the Job Server’s email destination settings, and if so, that will perform the authentication that Exchange is requiring in order to send the external emails. I would just give it a shot and see if it works. Note that there is no AD authentication going on between the Job Server and Exchange – it’s simply the username/password that’s entered in the destination settings.
My client works with Office 365.
I’ve tried my different possibilities of information but each time I try to run a simple schedule to an external email address, I get an error message:
This one is when nothing is entered (domain name, user name and pwd are empty… port = 25)
This one is when I put data (domain name, User Name, Pwd, Port…)
I’m not sure I enter the right data but I can’t find any documentation detailed enough to help me…
If you have any idea… I take everything !
Thanks in advance
Yes, this error is pretty much useless as too many of them seem to be.
I’ve had a some more thoughts about this since my first post. You know how your subconscious works on things when you aren’t?
It seems to me that the login ID that you are entering only appears to be valid for your internal domain. Your domain account may not be authenticating to both domains. This might explain why the emails are successful to the internal addresses but not the external ones. There is an assumption here that the internal domain and the external domain are different. I don’t know much about Active Directory so I don’t know if it is possible to configure a single account to authenticate to multiple domains.
I also was wondering if your external domain needed to be added to your krb5.ini file, assuming you are using Kerberos but that primarily supports single sign-on into Business Objects and not connecting from Business Objects to Active Directory. I could certainly be wrong about that, but you might be in a unique position to test it.
(BOB member since 2005-03-29)
(BOB member since 2002-08-29)
