Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Sep 11, 2012 03:03 AM by JerryHsi
Aug 09, 2012 09:47 PM|LINK
I have a WCF authentication service that uses active directory membership provider class and provides AD login function and we have this working for one domain A. There is another domain B which is behind the firewall and there is a one way trust relationship
between domain A and B. Users from domain B can log onto the domain controller of domain A but not vice versa. The WCF service is on Domain A. I tried to authenticate users from domain B using the service and I received the unknown username or bad password
I am wondering if anyone know if the active directory membership provider works across multiple domain with one way trust relationship? I have tried changing the LDAP connection string to point to domain A's domain controller but specify the DC parameter
to Domain B and set the connectionUser to DomainB\Username but I received the same error. If I have everything pointing to DomainA I receives the same error too. The domain controllers for A and B can see each other. Does anyone know a solution?
(We can't point the LDAP string to domain B as its behind firewalls)
Does this scenario requires a particular type of trust or trust relationship?
I think we are using one way forest trust.
The authentication is working for a single domain but not across the domain. We are using standard ASP.NET 2.0 Active Directory Membership provider, so there is no custom implementations in the WCF service. We wanted to achieve authentication across a one-way
trust. The following is the WCF's web.config file:
<add name="ADProviderConnection" connectionString="LDAP://DomainA"/>
<compilation debug="true" targetFramework="4.0" />
<membership defaultProvider="ADMembershipProvider" >
As you can see from the config file, we are using a service account from domain A to connect to domain A's domain controller, this all works great when we are authenticating domain A users, but when we tried to authenticate domain B users, the authentication
My questions is if the trust is set up correctly, the membership provider should work given the LDAP string to domain A and service account of domain A, the provider should be able to resolve and authenticate domain B users through the trust relationship,
although we are connecting to domain controller of domain A?
Does the membership provider support this? If not what should the LDAP string and connectionUser account be changed to?
We have also tried to use a Domain B account for the connectionUser and keep the LDAP connection string the same, but we were not able to get it to work. Is it correct to assume that having a domain B account but with a LDAP string pointing to domain A should
work because we have a trust relationship set up?? It will automagically forward the authentication request to domain B?
If we use domain A account do we need to setup permissions for that account in domain B so that it can access domain B?
How does windows authentication work in situation like this?
Does the membership provider uses the same mechanism as windows authentication underneath?
Thank you very much!
Aug 23, 2012 07:40 PM|LINK
Did you ever find a solution to your problem? I had a similar issue, but ended up writing my own membership provider to resolve this. A bit of a pain, but it will work.
Aug 24, 2012 04:08 AM|LINK
Hi Zanman2112, Thanks for the reply. No I haven't find a solution to this problem. I am using the standard ASP.NET membership provider from Microsoft and it doesn't seem to work for cross domain authentication with one way trust.
Aug 24, 2012 01:02 PM|LINK
Hey, Jerry. Yeah, that was what I found too. I even tried to create a group in Domain A that pointed to a group Domain B to get around the problem. Even though it looked like it should work, the Membership Provider wasn't having any of it. Again, my
ultimate solution was to write my own Membership and Role Providers. It was a bit of a pain, so if you do decide to go in that direction, I would be happy to help if you have any questions about it.
Aug 26, 2012 10:54 AM|LINK
Thanks very much Zanman2112, before I go into this direction - I wonder if there is any way that we can change the LDAP connection string to get it working, Membership provder uses LDAP and LDAP should support search across forests. I saw this post on chase
Aug 29, 2012 04:50 AM|LINK
I think I am going down the path of writing my own AD membership provider. Are you using the .NET's Directory Services API? Hopefully I can get it to traverse the trust using referral chasing and GC search.
Aug 29, 2012 12:02 PM|LINK
I am facing the same situation. We have SharePoint sites setup working fine with the trust domain, but the ASP.Net ActiveDirectoryMembershipProvider wont work.
Using LDAP I get the message "A referral was returned from the server.", unfortunately the webserver can't see
the second AD server due to firewalls, so I can't query it directly.
I can perform queries fine using the .NET directory services if I use GC://domain instead of LDAP://domain however this doesn't work with ASP.Net ActiveDirectoryMembershipProvider ("Only LDAP connection strings are supported against Active Directory and
Apparently this is by design, as things like reset password and creating new users wont work on the trusted domain. But I'm not interested in any of that - I just want to authenticate the users.
It seems a bit overkill to re-write the membership provider, does it not?
Aug 29, 2012 09:18 PM|LINK
yeah I got the exact same error as you using AD membership provider. Sounds like the domains are in the same forest and you can query GC. I have two separated forests which makes it very difficult.
Sep 07, 2012 08:34 PM|LINK
Hey, Jerry. Sorry I didn't get back earlier. Yes, that is correct. And it should be able to traverse the domains, although you will need to connect to each domain seperately using a domain account with directory read access.
Sep 09, 2012 09:46 PM|LINK
Hi Zanman2112, I have done a basic membership provider with only a single validate user method. I used LDAP query against rootDSE object. It seems to work and I am still testing it. For role based authentication I just used selective authentication and authentication
firewall in 2008 R2.