The credentials that Outlook passes to the Exchange server are the credentials with which the user logged into the local pc, which are not necessarily the same credentials that they authenticated through the IVE...
If I understand what you're asking.
I know that Network Connect has the ability to survive logoff/logon to allow direct authentication against an AD server, But I don't think you can do this via WSAM.
In the Autopolicy you will need an entry for each of your Domain Controllers like so: 192.168.1.88:88,389,636 Allow
192.168.1.89:88,389,636 Allow
636 is needed if you are using LDAPS/StartTLS.
However, the user must already be logged into the PC as a domain user, and the PC must have been connected to the domain within the last (i think its 31) 31 days, or the machine account password will have expired (you'll have to check Microsoft's KBs to confirm this). If your users log on locally, then MS will require that they enter valid domain credentials to communicate with their mailbox.
I seem to remember similar issues back in the days of NT4 and ISDN where remote users would not use their home machines for a month or so and when they did try to connect, their machine was no longer trusted by the DC. I think we had to remote control their machine, change the local admin password, move the machine to a workgroup and after the reboot, have the user log in as local admin and join the domain again. after which we would reset the local admin account again, and they were back in business.
Today, your users are probably laptop users, and will have had the machine on the LAN recently enough that this should not be a problem.
I put *:* in the auto policy to be sure it is not linked to ACLs
My test PC is logged with the domain user account (Cached credentials) and were on the corp network the same day wihtout any issue. (Session open on the domain with netlogon script)
Do you confirm it works for you using the WSAM since your upgrade to version 6.4r1 ?
Thanks
If I am not wrong, do you need SSO(Kerberos) for your OUTLOOK via WSAM?
If so, SSO for WSAM, JSAM & NC is not yet supported.
Password Management is supported via WSAM & NC, like changing your NT password.
My Outlook & Wsam is finally working. Going to outlook
Tools > account settings > change > more settings > security
set logon network security to NTLM (outlook 2007) this did the trick.
Live Communicator & Network Shares still not working :-(
I think it has to do with dns resolution. Wireshars showes that DNS request for kerberos services is not being resolved by WSAM.
@speedygonzales wrote:Live Communicator & Network Shares still not working :-(
I think it has to do with dns resolution. Wireshars showes that DNS request for kerberos services is not being resolved by WSAM.
Yeah, that seems to make sense since file servers use kerberos. Its funny, but I remember file sharing with WSAM working in 5.2 OS, but after 5.3 things like that broke and never got fixed.
What really is strange is that filesharing w/ WSAM works when VPN'd from another zone off the firewall which has no access, but it doesn't when the computer is totally remote. Error 53 Network path not found.
@speedygonzales wrote:I think it has to do with dns resolution. Wireshars showes that DNS request for kerberos services is not being resolved by WSAM.
If you have narrowed it down to DNS then you may want to try 6.5R2 as the below 2 issues related to kerberos Auth via WSAM were fixed in that release:
1. Kerberos auth over WSAM not working until dns and netbios cache on PC are not flushed (fixed in 6.5R1 as well)
2. Kerberos auth over WSAM fails when DNS response for KDC is large (i.e. Switches from udp to tcp)