ActiveDirectoryMembershipProvider woes

Discussion in 'ASP .Net Security' started by Thomas, Jul 8, 2009.

  1. Thomas

    Thomas Guest

    Ok, I've run into the same problem at a different company. Some time ago I
    posted this:
    http://groups.google.com/group/micr...ecurity/browse_thread/thread/d6d44686f14fdf61

    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.

    Access list:
    Effective Permissions on this object are:
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS
    READ PERMISSONS
    Allow FOO\Domain Admins SPECIAL ACCESS
    READ PERMISSONS
    WRITE PERMISSIONS
    CHANGE OWNERSHIP
    CREATE CHILD
    LIST CONTENTS
    WRITE SELF
    WRITE PROPERTY
    READ PROPERTY
    LIST OBJECT
    CONTROL ACCESS
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS
    LIST CONTENTS
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Allow FOO\Enterprise Admins FULL CONTROL
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS
    READ PERMISSONS
    READ PROPERTY
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS
    LIST CONTENTS
    Allow BUILTIN\Administrators SPECIAL ACCESS
    DELETE
    READ PERMISSONS
    WRITE PERMISSIONS
    CHANGE OWNERSHIP
    CREATE CHILD
    LIST CONTENTS
    WRITE SELF
    WRITE PROPERTY
    READ PROPERTY
    LIST OBJECT
    CONTROL ACCESS
    Allow Everyone SPECIAL ACCESS
    READ PROPERTY
    Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Allow NT AUTHORITY\SYSTEM FULL CONTROL
    Allow FOO\Exchange Recipient Administrators FULL CONTROL for
    msExchDynamicDistributionList
    Allow FOO\Exchange Servers SPECIAL ACCESS for Exchange
    Personal Information
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    canonicalName
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    userAccountControl
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for Exchange
    Information
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for memberOf
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    garbageCollPeriod
    READ PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    proxyAddresses
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    showInAddressBook
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for Exchange
    Personal Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    adminDisplayName
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for
    groupType
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    groupType
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchMailboxSecurityDescriptor
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMServerWritableFlags
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for
    displayName
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    displayName
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Public
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUserCulture
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    displayNamePrintable
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for mail
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchMobileMailboxFlags
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    userCertificate
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Personal
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    textEncodedORAddress
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Exchange
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for Exchange
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    publicDelegates
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    publicDelegates
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMSpokenName
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    garbageCollPeriod
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMPinChecksum
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    legacyExchangeDN
    WRITE PROPERTY
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS for Domain
    Password & Lockout Policies
    READ PROPERTY
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS for Other
    Domain Parameters (for use by SAM)
    READ PROPERTY
    Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS for Other
    Domain Parameters (for use by SAM)
    READ PROPERTY
    Allow NT AUTHORITY\NETWORK SERVICE SPECIAL ACCESS for
    Exchange Personal Information
    READ PROPERTY
    Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS for
    Exchange Information
    READ PROPERTY
    Allow FOO\Exchange Enterprise Servers Manage Replication Topology
    Allow FOO\Domain Controllers Replicating Directory
    Changes All
    Allow FOO\Exchange Servers Change Password
    Allow BUILTIN\Administrators Replicating Directory
    Changes
    Allow BUILTIN\Administrators Replication
    Synchronization
    Allow BUILTIN\Administrators Manage Replication
    Topology
    Allow BUILTIN\Administrators Replicating Directory
    Changes All
    Allow S-1-5-32-557 Create Inbound Forest
    Trust
    Allow NT AUTHORITY\Authenticated Users Enable Per User Reversibly
    Encrypted Password
    Allow NT AUTHORITY\Authenticated Users Unexpire Password
    Allow NT AUTHORITY\Authenticated Users Update Password Not
    Required Bit
    Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Replicating Directory
    Changes
    Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Replication
    Synchronization
    Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS Manage Replication
    Topology

    Permissions inherited to subobjects are:
    Inherited to all subobjects
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS
    LIST CONTENTS
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Allow FOO\Enterprise Admins FULL CONTROL
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS
    LIST CONTENTS
    Allow BUILTIN\Administrators SPECIAL ACCESS
    DELETE
    READ PERMISSONS
    WRITE PERMISSIONS
    CHANGE OWNERSHIP
    CREATE CHILD
    LIST CONTENTS
    WRITE SELF
    WRITE PROPERTY
    READ PROPERTY
    LIST OBJECT
    CONTROL ACCESS
    Allow FOO\Exchange Recipient Administrators FULL CONTROL for
    msExchDynamicDistributionList
    Allow FOO\Exchange Servers SPECIAL ACCESS for Exchange
    Personal Information
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    canonicalName
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    userAccountControl
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for Exchange
    Information
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for memberOf
    READ PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    garbageCollPeriod
    READ PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    proxyAddresses
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    showInAddressBook
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for Exchange
    Personal Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    adminDisplayName
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for
    groupType
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    groupType
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchMailboxSecurityDescriptor
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMServerWritableFlags
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for
    displayName
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    displayName
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Public
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUserCulture
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    displayNamePrintable
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for mail
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchMobileMailboxFlags
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    userCertificate
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Personal
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    textEncodedORAddress
    WRITE PROPERTY
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS for Exchange
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for Exchange
    Information
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    publicDelegates
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    publicDelegates
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMSpokenName
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    garbageCollPeriod
    WRITE PROPERTY
    Allow FOO\Exchange Servers SPECIAL ACCESS for
    msExchUMPinChecksum
    WRITE PROPERTY
    Allow FOO\Exchange Recipient Administrators SPECIAL ACCESS for
    legacyExchangeDN
    WRITE PROPERTY
    Allow NT AUTHORITY\NETWORK SERVICE SPECIAL ACCESS for
    Exchange Personal Information
    READ PROPERTY
    Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS for
    Exchange Information
    READ PROPERTY
    Allow FOO\Exchange Servers Change Password

    Inherited to user
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Inherited to group
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Inherited to user
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Inherited to group
    Allow FOO\Exchange Enterprise Servers SPECIAL ACCESS
    READ PERMISSONS
    LIST CONTENTS
    READ PROPERTY
    LIST OBJECT
    Allow FOO\Exchange Servers SPECIAL ACCESS
    WRITE PERMISSIONS
    Inherited to user
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS for Remote
    Access Information
    READ PROPERTY
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS for Logon
    Information
    READ PROPERTY
    Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL ACCESS for Account
    Restrictions
    READ PROPERTY
    The command completed successfully
     
    Thomas, Jul 8, 2009
    #1
    1. Advertising

  2. Thomas

    Thomas Guest

    As a following up, I did find this:
    http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >
    > 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>
     
    Thomas, Jul 8, 2009
    #2
    1. Advertising

  3. Thomas

    Joe Kaplan Guest

    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:D...
    > As a following up, I did find this:
    > http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >>
    >> 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>
     
    Joe Kaplan, Jul 8, 2009
    #3
  4. Thomas

    Thomas Guest

    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:D...
    >> As a following up, I did find this:
    >> http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >>>
    >>> 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>

    >
     
    Thomas, Jul 8, 2009
    #4
  5. Thomas

    Thomas Guest

    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:...
    > 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:D...
    >>> As a following up, I did find this:
    >>> http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >>>>
    >>>> 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>

    >>

    >
     
    Thomas, Jul 8, 2009
    #5
  6. Thomas

    Thomas Guest

    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:...
    >> 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:D...
    >>>> As a following up, I did find this:
    >>>> http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >>>>>
    >>>>> 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>
    >>>

    >>

    >
     
    Thomas, Jul 8, 2009
    #6
  7. Thomas

    Joe Kaplan Guest

    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:...
    >>> 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:D...
    >>>>> As a following up, I did find this:
    >>>>> http://world.episerver.com/Document...-to-Use-Active-Directory-Membership-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/micr...ecurity/browse_thread/thread/d6d44686f14fdf61
    >>>>>>
    >>>>>> 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>
    >>>>
    >>>

    >>

    >
     
    Joe Kaplan, Jul 8, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arnel
    Replies:
    3
    Views:
    4,728
    =?Utf-8?B?UGF0cmljay5PLklnZQ==?=
    Oct 31, 2005
  2. Natan Vivo
    Replies:
    1
    Views:
    647
    Patrick.O.Ige
    Oct 31, 2005
  3. Replies:
    0
    Views:
    635
  4. =?Utf-8?B?SkQgUWl4Y2xl?=
    Replies:
    2
    Views:
    5,230
    =?Utf-8?B?SkQgUWl4Y2xl?=
    Jun 9, 2006
  5. moi
    Replies:
    1
    Views:
    5,832
Loading...

Share This Page