Got a site up and runnig with windowsroleprovider. It works fine allright. Users are logged in allright. And got usernames like <domain>\firstname.lastname. So faar so good.
BUT :DI'm developeing a connection to Exchange to deliver calender-events and stuff, authenticated by "Windows authentication". If I run the feature under an console-application ( as a valid domainuser ) i will be authenticated and stuff will happen in Exchange. but if I run the feature from an EPiServer page i will still get authenticated ( i think, i don't get any 401 or 407 errors ) But i do get an exchange-error ( se below ) that makes mee confused...
ResponseCode: ErrorMissingEmailAddressMessageText: When making a request as an account that does not have a mailbox, you must specify the mailbox primary SMTP address for any distinguished folder Ids.
I have tried both of System.Net.CredentialCache.DefaultNetworkCredentials or System.Net.CredentialCache.DefaultCredentials as credential with the same result.
If i change the authentication-type to BASIC and pass username and password I will also get authenticated and then no errors at all from exchange...
I have also tried to use "Impersonalisation" but then I cant get site running at all... "An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode." and if i change pool's managed pipeline mode to "Classic" i gets an notification that "EPiServer CMS - This installation contains only core files. "
Conclusion: I think my WindowsRoleProvider doesn't pass my email-address somehow... does anyone have an idéa for me? where to start looking...
Have you tried setting the "Load user profile" flag on the application pool to true?
I would examine the HttpContext.User to determine whether your client is properly authenticated. Impersonation means that IIS should try to 'take on' the identity of the client, which means that IIS will access the filesystem (and other resources) as that user. For those experienced in *NIX like environments, this can be compared as the web-server 'sudo-ing' to the identity of the client for the duration of the request.
The 'core files' issue might be because the HttpModules and HttpHandlers in your web config are configured in a way that assumes you are running in integrated pipeline mode. If you change to Classic mode, you should probably change the preCondition attribute of the httpHandlers+modules in your configuration.
I think the reason why Exchange complains is that the IIS process runs under the identity of the application pool - which probably doesn't have an email address configured ;)
Maybe you can use the HttpContext.User (which is an IPrincipal object) to tell your exchange connector the credentials to use?
1. Yes, "Load user profile" is set to true!
2. Yes, I was using Page.User.Identity.Name to determine "me" and it shure looks like it's a good user. NOT IUSER or one of his cousines.
The impersonation part do I want to avoid as long as possible, but maybee it's the only way to let the "real" usercredentials be passed to exchange.
"I have tried both of System.Net.CredentialCache.DefaultNetworkCredentials or System.Net.CredentialCache.DefaultCredentials as credential with the same result."
I was thinking, maybe you can try with a credential set derived from HttpContext.User?
This is known as a "double-hop" problem where you need to use Kerberos Authentication, Service Principal Names (SPNs) and delegation.It's a little bit tricky to implement but you'll find some usefull information about it here: http://www.adopenstatic.com/faq/
"This is known as a 'double-hop' problem... " - wow, does it even got a name :D.
This sounds promissing... I will lock in to that in a week or so...