| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
Is the Domain Users group part of the Pre-Win2K compat access group? In
many cases permissions are delegated to the Pre-Win2K group but in some domains the Domain Users group is not included in this group so normal users only end up getting the permissions that are delegated to Authenticated Users instead. This may be part of your issue. Another approach would be to consider trying the ldp.exe tool to connect to the directory, bind with the creds of your service account and then try to search for users in the directory and see what attributes can be returned. That may shed some light. Any reason why you need to use the AD membership provider? Can you skip the forms auth and just use Windows auth instead? -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net "Thomas" <> wrote in message news  A199A56-B63C-4096-9D56-...> As a following up, I did find this: > http://world.episerver.com/Documenta...ship-Provider/ > > Which lists out the permissions, but connecting the permissions it states > that the auth user needs and determining which ones it doesn't on what is > trickier. > > > Thomas > > > > "Thomas" wrote: > >> Ok, I've run into the same problem at a different company. Some time ago >> I >> posted this: >> http://groups.google.com/group/micro...d44686f14fdf61 >> >> The short version is that I'm setting up a site using FormsAuthentication >> and the ActiveDirectoryMembership provider. I suspect given the >> "wonderful" >> error messages that I'm getting that the user account I was given is >> missing >> some permissions somewhere. The problem is that tracking down what >> permissions are missing is a serious bear. At the last company where I >> ran >> into this problem, they punted and made the user used for authentication >> a >> Domain Admin because we could not track down the problem. >> >> I'm really trying to find an actionable solution that I can give to >> relatively inexperienced domain admin to fix. To that end, I'm trying to >> use >> the acldiags and dsacls to hopeful detemrine what is missing but I can't >> make heads or tails of the output. >> >> Here is the output from dsacls run from a command prompt as the user I'm >> trying to use for authentication (domain has been changed obviously). >> This >> is a 2003 Domain as far as I can tell. > <snip> |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Domain Users are indeed members of the Pre-Windows 2000 Compatible Access group as are Authenticated Users and Exchange Domain Servers. I used the ldp tool to query for a UPN I know to exist (verified via the ADSI tool). I used the following filter: (userPrincipalName=) and I got the following: ***Searching... ldap_search_s(ld, "DC=co,DC=foo,DC=com", 2, "(userPrincipalName=)", attrList, 0, &msg) Error: Search: Referral. <10> Server error: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points ref 1: 'CO.FOO.COM' Result <10>: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points ref 1: 'CO.FOO.COM' Matched DNs: Getting 0 entries: Notice that they have remapped the UPN from co.foo.com to just foo.com. Regardless, I'm not sure what to make of the results. Thomas "Joe Kaplan" <> wrote in message news:ui4BoI9$... > Is the Domain Users group part of the Pre-Win2K compat access group? In > many cases permissions are delegated to the Pre-Win2K group but in some > domains the Domain Users group is not included in this group so normal > users only end up getting the permissions that are delegated to > Authenticated Users instead. This may be part of your issue. > > Another approach would be to consider trying the ldp.exe tool to connect > to the directory, bind with the creds of your service account and then try > to search for users in the directory and see what attributes can be > returned. That may shed some light. > > Any reason why you need to use the AD membership provider? Can you skip > the forms auth and just use Windows auth instead? > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services > Programming" > http://www.directoryprogramming.net > "Thomas" <> wrote in message > news A199A56-B63C-4096-9D56-...>> As a following up, I did find this: >> http://world.episerver.com/Documenta...ship-Provider/ >> >> Which lists out the permissions, but connecting the permissions it states >> that the auth user needs and determining which ones it doesn't on what is >> trickier. >> >> >> Thomas >> >> >> >> "Thomas" wrote: >> >>> Ok, I've run into the same problem at a different company. Some time ago >>> I >>> posted this: >>> http://groups.google.com/group/micro...d44686f14fdf61 >>> >>> The short version is that I'm setting up a site using >>> FormsAuthentication >>> and the ActiveDirectoryMembership provider. I suspect given the >>> "wonderful" >>> error messages that I'm getting that the user account I was given is >>> missing >>> some permissions somewhere. The problem is that tracking down what >>> permissions are missing is a serious bear. At the last company where I >>> ran >>> into this problem, they punted and made the user used for authentication >>> a >>> Domain Admin because we could not track down the problem. >>> >>> I'm really trying to find an actionable solution that I can give to >>> relatively inexperienced domain admin to fix. To that end, I'm trying to >>> use >>> the acldiags and dsacls to hopeful detemrine what is missing but I can't >>> make heads or tails of the output. >>> >>> Here is the output from dsacls run from a command prompt as the user I'm >>> trying to use for authentication (domain has been changed obviously). >>> This >>> is a 2003 Domain as far as I can tell. >> <snip> > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Ok, I think I'm closer. In the ldp search, I checked "Chase Referrals" and that found the user. Which leads me to believe that the AD Membership Provider does not chase referrals and thus cannot find the user. Is there a way to know whether the AD Membership Provider chases referrals? Is there a way to force it to do so if it does not? To answer the earlier question, we have a custom role provider and getting it to work with Windows Auth was problematic. We could of course try again, but I found that Windows Auth does not behave like a "typical" forms auth provider. IIRC, the browsers do not behave nicely with Windows Auth. Something that MS did to IE causes Windows Auth to still throw up a login dialog even if the user is on the domain (or even the same machine as IIS.) Thomas "Thomas" <> wrote in message news:ADB2E4A3-61B6-421D-ACCE-... > Domain Users are indeed members of the Pre-Windows 2000 Compatible Access > group as are Authenticated Users and Exchange Domain Servers. > > I used the ldp tool to query for a UPN I know to exist (verified via the > ADSI tool). I used the following filter: > (userPrincipalName=) and I got the following: > > ***Searching... > ldap_search_s(ld, "DC=co,DC=foo,DC=com", 2, > "(userPrincipalName=)", attrList, 0, &msg) > Error: Search: Referral. <10> > Server error: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points > ref 1: 'CO.FOO.COM' > > Result <10>: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points > ref 1: 'CO.FOO.COM' > > Matched DNs: > Getting 0 entries: > > Notice that they have remapped the UPN from co.foo.com to just foo.com. > Regardless, I'm not sure what to make of the results. > > > Thomas > > "Joe Kaplan" <> wrote in message > news:ui4BoI9$... >> Is the Domain Users group part of the Pre-Win2K compat access group? In >> many cases permissions are delegated to the Pre-Win2K group but in some >> domains the Domain Users group is not included in this group so normal >> users only end up getting the permissions that are delegated to >> Authenticated Users instead. This may be part of your issue. >> >> Another approach would be to consider trying the ldp.exe tool to connect >> to the directory, bind with the creds of your service account and then >> try to search for users in the directory and see what attributes can be >> returned. That may shed some light. >> >> Any reason why you need to use the AD membership provider? Can you skip >> the forms auth and just use Windows auth instead? >> >> -- >> Joe Kaplan-MS MVP Directory Services Programming >> Co-author of "The .NET Developer's Guide to Directory Services >> Programming" >> http://www.directoryprogramming.net >> "Thomas" <> wrote in message >> news A199A56-B63C-4096-9D56-...>>> As a following up, I did find this: >>> http://world.episerver.com/Documenta...ship-Provider/ >>> >>> Which lists out the permissions, but connecting the permissions it >>> states >>> that the auth user needs and determining which ones it doesn't on what >>> is >>> trickier. >>> >>> >>> Thomas >>> >>> >>> >>> "Thomas" wrote: >>> >>>> Ok, I've run into the same problem at a different company. Some time >>>> ago I >>>> posted this: >>>> http://groups.google.com/group/micro...d44686f14fdf61 >>>> >>>> The short version is that I'm setting up a site using >>>> FormsAuthentication >>>> and the ActiveDirectoryMembership provider. I suspect given the >>>> "wonderful" >>>> error messages that I'm getting that the user account I was given is >>>> missing >>>> some permissions somewhere. The problem is that tracking down what >>>> permissions are missing is a serious bear. At the last company where I >>>> ran >>>> into this problem, they punted and made the user used for >>>> authentication a >>>> Domain Admin because we could not track down the problem. >>>> >>>> I'm really trying to find an actionable solution that I can give to >>>> relatively inexperienced domain admin to fix. To that end, I'm trying >>>> to use >>>> the acldiags and dsacls to hopeful detemrine what is missing but I >>>> can't >>>> make heads or tails of the output. >>>> >>>> Here is the output from dsacls run from a command prompt as the user >>>> I'm >>>> trying to use for authentication (domain has been changed obviously). >>>> This >>>> is a 2003 Domain as far as I can tell. >>> <snip> >> > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
According to Schackow, the ADMP does not chase referrals, so I'm going to
try to narrow the container search by the ADMP and see if that fixes the problem. Thomas "Thomas" <> wrote in message news:ODv5Gi%23$... > Ok, I think I'm closer. In the ldp search, I checked "Chase Referrals" and > that found the user. Which leads me to believe that the AD Membership > Provider does not chase referrals and thus cannot find the user. Is there > a way to know whether the AD Membership Provider chases referrals? Is > there a way to force it to do so if it does not? > > To answer the earlier question, we have a custom role provider and getting > it to work with Windows Auth was problematic. We could of course try > again, but I found that Windows Auth does not behave like a "typical" > forms auth provider. IIRC, the browsers do not behave nicely with Windows > Auth. Something that MS did to IE causes Windows Auth to still throw up a > login dialog even if the user is on the domain (or even the same machine > as IIS.) > > > Thomas > > > "Thomas" <> wrote in message > news:ADB2E4A3-61B6-421D-ACCE-... >> Domain Users are indeed members of the Pre-Windows 2000 Compatible Access >> group as are Authenticated Users and Exchange Domain Servers. >> >> I used the ldp tool to query for a UPN I know to exist (verified via the >> ADSI tool). I used the following filter: >> (userPrincipalName=) and I got the following: >> >> ***Searching... >> ldap_search_s(ld, "DC=co,DC=foo,DC=com", 2, >> "(userPrincipalName=)", attrList, 0, &msg) >> Error: Search: Referral. <10> >> Server error: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points >> ref 1: 'CO.FOO.COM' >> >> Result <10>: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points >> ref 1: 'CO.FOO.COM' >> >> Matched DNs: >> Getting 0 entries: >> >> Notice that they have remapped the UPN from co.foo.com to just foo.com. >> Regardless, I'm not sure what to make of the results. >> >> >> Thomas >> >> "Joe Kaplan" <> wrote in message >> news:ui4BoI9$... >>> Is the Domain Users group part of the Pre-Win2K compat access group? In >>> many cases permissions are delegated to the Pre-Win2K group but in some >>> domains the Domain Users group is not included in this group so normal >>> users only end up getting the permissions that are delegated to >>> Authenticated Users instead. This may be part of your issue. >>> >>> Another approach would be to consider trying the ldp.exe tool to connect >>> to the directory, bind with the creds of your service account and then >>> try to search for users in the directory and see what attributes can be >>> returned. That may shed some light. >>> >>> Any reason why you need to use the AD membership provider? Can you skip >>> the forms auth and just use Windows auth instead? >>> >>> -- >>> Joe Kaplan-MS MVP Directory Services Programming >>> Co-author of "The .NET Developer's Guide to Directory Services >>> Programming" >>> http://www.directoryprogramming.net >>> "Thomas" <> wrote in message >>> news A199A56-B63C-4096-9D56-...>>>> As a following up, I did find this: >>>> http://world.episerver.com/Documenta...ship-Provider/ >>>> >>>> Which lists out the permissions, but connecting the permissions it >>>> states >>>> that the auth user needs and determining which ones it doesn't on what >>>> is >>>> trickier. >>>> >>>> >>>> Thomas >>>> >>>> >>>> >>>> "Thomas" wrote: >>>> >>>>> Ok, I've run into the same problem at a different company. Some time >>>>> ago I >>>>> posted this: >>>>> http://groups.google.com/group/micro...d44686f14fdf61 >>>>> >>>>> The short version is that I'm setting up a site using >>>>> FormsAuthentication >>>>> and the ActiveDirectoryMembership provider. I suspect given the >>>>> "wonderful" >>>>> error messages that I'm getting that the user account I was given is >>>>> missing >>>>> some permissions somewhere. The problem is that tracking down what >>>>> permissions are missing is a serious bear. At the last company where I >>>>> ran >>>>> into this problem, they punted and made the user used for >>>>> authentication a >>>>> Domain Admin because we could not track down the problem. >>>>> >>>>> I'm really trying to find an actionable solution that I can give to >>>>> relatively inexperienced domain admin to fix. To that end, I'm trying >>>>> to use >>>>> the acldiags and dsacls to hopeful detemrine what is missing but I >>>>> can't >>>>> make heads or tails of the output. >>>>> >>>>> Here is the output from dsacls run from a command prompt as the user >>>>> I'm >>>>> trying to use for authentication (domain has been changed obviously). >>>>> This >>>>> is a 2003 Domain as far as I can tell. >>>> <snip> >>> >> > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Ok, it sounds like you have a multi-domain forest involved here. I'm not sure if the ADMP can use the global catalog or not, but that is usually the appropriate solution for dealing with multi-domain issues. Win Auth *should* work fine with domain joined machines. Usually when it doesn't, it is an IE config issue. Things can get wonky on the public internet as you can't get Kerb auth in that situation since the DC is not available to get the service ticket from, but NTLM should still work. In terms of making it work with a custom role provider, it really should just be a case of taking the user identifier provided by the authentication mechanism to look up the user's roles, right? So I wouldn't think that part would be a huge issue. However, if you can't get the browser behavior you are looking for in a reasonable way and really want the forms auth, then trying to get ADMP working is probably the thing to do. Best of luck! -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net "Thomas" <> wrote in message news:%23XHIBk%23$... > According to Schackow, the ADMP does not chase referrals, so I'm going to > try to narrow the container search by the ADMP and see if that fixes the > problem. > > > Thomas > > > "Thomas" <> wrote in message > news:ODv5Gi%23$... >> Ok, I think I'm closer. In the ldp search, I checked "Chase Referrals" >> and that found the user. Which leads me to believe that the AD Membership >> Provider does not chase referrals and thus cannot find the user. Is there >> a way to know whether the AD Membership Provider chases referrals? Is >> there a way to force it to do so if it does not? >> >> To answer the earlier question, we have a custom role provider and >> getting it to work with Windows Auth was problematic. We could of course >> try again, but I found that Windows Auth does not behave like a "typical" >> forms auth provider. IIRC, the browsers do not behave nicely with Windows >> Auth. Something that MS did to IE causes Windows Auth to still throw up a >> login dialog even if the user is on the domain (or even the same machine >> as IIS.) >> >> >> Thomas >> >> >> "Thomas" <> wrote in message >> news:ADB2E4A3-61B6-421D-ACCE-... >>> Domain Users are indeed members of the Pre-Windows 2000 Compatible >>> Access group as are Authenticated Users and Exchange Domain Servers. >>> >>> I used the ldp tool to query for a UPN I know to exist (verified via the >>> ADSI tool). I used the following filter: >>> (userPrincipalName=) and I got the following: >>> >>> ***Searching... >>> ldap_search_s(ld, "DC=co,DC=foo,DC=com", 2, >>> "(userPrincipalName=)", attrList, 0, &msg) >>> Error: Search: Referral. <10> >>> Server error: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points >>> ref 1: 'CO.FOO.COM' >>> >>> Result <10>: 0000202B: RefErr: DSID-0310063C, data 0, 1 access points >>> ref 1: 'CO.FOO.COM' >>> >>> Matched DNs: >>> Getting 0 entries: >>> >>> Notice that they have remapped the UPN from co.foo.com to just foo.com. >>> Regardless, I'm not sure what to make of the results. >>> >>> >>> Thomas >>> >>> "Joe Kaplan" <> wrote in message >>> news:ui4BoI9$... >>>> Is the Domain Users group part of the Pre-Win2K compat access group? >>>> In many cases permissions are delegated to the Pre-Win2K group but in >>>> some domains the Domain Users group is not included in this group so >>>> normal users only end up getting the permissions that are delegated to >>>> Authenticated Users instead. This may be part of your issue. >>>> >>>> Another approach would be to consider trying the ldp.exe tool to >>>> connect to the directory, bind with the creds of your service account >>>> and then try to search for users in the directory and see what >>>> attributes can be returned. That may shed some light. >>>> >>>> Any reason why you need to use the AD membership provider? Can you >>>> skip the forms auth and just use Windows auth instead? >>>> >>>> -- >>>> Joe Kaplan-MS MVP Directory Services Programming >>>> Co-author of "The .NET Developer's Guide to Directory Services >>>> Programming" >>>> http://www.directoryprogramming.net >>>> "Thomas" <> wrote in message >>>> news A199A56-B63C-4096-9D56-...>>>>> As a following up, I did find this: >>>>> http://world.episerver.com/Documenta...ship-Provider/ >>>>> >>>>> Which lists out the permissions, but connecting the permissions it >>>>> states >>>>> that the auth user needs and determining which ones it doesn't on what >>>>> is >>>>> trickier. >>>>> >>>>> >>>>> Thomas >>>>> >>>>> >>>>> >>>>> "Thomas" wrote: >>>>> >>>>>> Ok, I've run into the same problem at a different company. Some time >>>>>> ago I >>>>>> posted this: >>>>>> http://groups.google.com/group/micro...d44686f14fdf61 >>>>>> >>>>>> The short version is that I'm setting up a site using >>>>>> FormsAuthentication >>>>>> and the ActiveDirectoryMembership provider. I suspect given the >>>>>> "wonderful" >>>>>> error messages that I'm getting that the user account I was given is >>>>>> missing >>>>>> some permissions somewhere. The problem is that tracking down what >>>>>> permissions are missing is a serious bear. At the last company where >>>>>> I ran >>>>>> into this problem, they punted and made the user used for >>>>>> authentication a >>>>>> Domain Admin because we could not track down the problem. >>>>>> >>>>>> I'm really trying to find an actionable solution that I can give to >>>>>> relatively inexperienced domain admin to fix. To that end, I'm trying >>>>>> to use >>>>>> the acldiags and dsacls to hopeful detemrine what is missing but I >>>>>> can't >>>>>> make heads or tails of the output. >>>>>> >>>>>> Here is the output from dsacls run from a command prompt as the user >>>>>> I'm >>>>>> trying to use for authentication (domain has been changed obviously). >>>>>> This >>>>>> is a 2003 Domain as far as I can tell. >>>>> <snip> >>>> >>> >> > |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| ActiveDirectoryMembershipProvider Object Reference not set ... | =?Utf-8?B?SkQgUWl4Y2xl?= | ASP .Net | 2 | 06-08-2006 11:40 PM |
| Membership credential verification failed With ActiveDirectoryMembershipProvider | moi | ASP .Net | 1 | 04-21-2006 05:05 PM |
| user schema change for ActiveDirectoryMembershipProvider | steven@sbcanada.com | ASP .Net | 0 | 11-01-2005 09:25 PM |
| ActiveDirectoryMembershipProvider ASP.NET 2.0 | Arnel | ASP .Net | 3 | 10-31-2005 06:02 AM |
| ActiveDirectoryMembershipProvider login always fail | Natan Vivo | ASP .Net | 1 | 10-31-2005 02:43 AM |
