ASP.Net/C# ADSI Reset Password "access denied" error(s)...
Sunny Gulati UGS
Having read through previous posts (Lysrian and Joe Kaplan exchanged a very
informative dialogue around 4/15), I think i'm on the right track, but I
wanted to make sure --
We have an application that sits on top of Windows Sharepoint Services.
One small part of it is a "Password Administrator" webpart that allows
specific users the ability manage passwords for uses in certain OU's.
The symptoms are:
0. Environment: Everything is Windows Server 2003.
1. When the customer attempts to reset somebody's password, they're getting
an "Access Denied" message all the time.
2. When we attempt to reset passwords, IF the password change is
successful, it works; if it is not successful (ie, complexity rules or
minimal length or history is violated), then instead of the appropriate
message, we get "Access Denied".
3. The code which invokes the password change looks like this:
DirectoryEntry de = new
DirectoryEntry("LDAP://tccperfad/dc=tccperf,dc=net","tccperf\administrator",
"xxxxxx",AuthenticationTypes.Secure);
// ---- Note: 1. full hostname being used. 2. attaching specifically as
administrator. ----
DirectorySearcher ds = new DirectorySearcher(de,"...."); SearchResult sr =
ds.FindOne();
DirectoryEntry deUsr = sr.GetDirectoryEntry();
deUsr.Invoke("SetPassword", new object[] { password });
4. When this code is run from a web forms app, it works just fine.
5. When this code is run from a ASP.Net webservice, it fails.
6. User is logging into the ASP.Net webservice using Basic Authentication.
Having read the above-mentioned thread, and having read these articles:
1.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/iadsuser_setpassword.asp
2. http://www.codecomments.com/ASP_.NET_Security/message451151.html
3. http://support.microsoft.com/default.aspx?scid=kb;en-us;321051
I decided to install an SSL certificate on our test environment domain
controller. That's when things got a bit interesting -- as far as I can
tell, i have a certificate installed now, but it just isn't setting up
LDAPS:// -- it gives the error: LDAP Interface/EventID 1220/LDAP over
Secure Sockets Layer (SSL) will be unavailable at this time because the
server was unable to obtain a certificate.
So, that's where I'm stuck at now. I could use some help in the following
ways:
1. Can you verify that installing LDAPS:// is in fact the way to go, as
opposed to some other thing like perhaps I'm using the wrong kind of
authentication, or perhaps it should have worked anyway because I'm using
explicit credentials?
2. Can you shed some light as to why the SetPassword call works, but at
other times instead of giving a "complexity requirements not met" exception
it gives an "Access Denied" exception?
3. Is there any better literature about setting up an LDAPS:// connection
than the KB article 321051 above? Note that the KB article has some
inconsistencies in it. Firstly, the sample for the certificate is badly
formatted and hard to decipher; Secondly, in windows 2003, there seems to be
a slightly more complicated key infrastructure; i may have installed the
certificate to the wrong place.
4. Are there any Microsoft development CA's that I can submit the cert to?
We have an internal CA here, but I'm not sure if I have registered it
correctly or not. Is there a way to test the cert chain?
If it would be helpful, I can provide an Appsight log that shows this
problem. Appsight is a tool that microsoft has an enterprise-wide license
to, which provides run-time debug logging -- useful for tracking down really
complex problems. It shows the exceptions that occur, and the stack traces
of the dll's that were called. I have a log of "SetPassword" working, and
"SetPassword" failing with an Access Denied exception.
Steven Cheng[MSFT]
Welcome to MSDN newsgroup.
From your description, the same code worked in an asp.net web application
but not work in webservice application. Regardless of the ADSI related
things, as for using Directory service in ASP.NET application, there is not
difference between ASP.NET webapplication and webservcie application. I'm
thinking that there must exists some difference on the security setting
between the WEBForm app and webservcie app you mentioned( IIS security and
ASP.NET security).
Are they on the same server and under the same IIS site? Would you please
provide us the complete security authentication setting of the two ASP.NET
application (in IIS and ASP.NET):
1. What authentication mode is the asp.net webform and webservice app using
in IIS?
2. What's the security setting in the web.config of the two web apps? using
"Windows" authentication? And have you configured to use impersonate ?
Also, based on my understanding, when we using the
AuthenticationTypes.Secure, the userName , password we specified in the
DirectoryEntry's constructor will be used for the authentication. So is
the
"tccperf\administrator"
you specified in the constuctor the domain administator or your local
comupter's admin? If it's the domain's admin, I'm really feeling a bit
strange since it not work.
Anyway, please have a check on the above things and let us know. Also, I'm
not sure whether you've ever read the below kb
#How to use the System.DirectoryServices namespace in ASP.NET
http://support.microsoft.com%3Fid=329986/
I think it has provide the most commonly occured erros and related security
concepts on access AD in asp.net. If there are anything unclear of the
security concepts mentioned in it, please also feel free to post here.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
Sunny Gulati UGS
It worked in a WINDOWS Form (they both start with "W", :[ )
It did not work in an ASP.Net application -- neither web service nor web
forms.
Identity/Impersonate is turned on -- the user is being impersonated on
the web server.
Yes, the tccperf\administrator is the domain administrator.
I will check out the link you described.
Please keep in mind that (in my experience, which differs from our
customer's), if complexity requirements are turned down on the domain
controller, the password reset works just fine -- its only when the
complexity requirements are turned up that the Access Denied error comes up.
If it would help, I can and would upload to you the web service I'm using to
test this out with? Or, if that would require a real ticket to be opened, I
could do that? (I'm not particularly familiar with all the levels of PSS
support, i'm not sure what is available to me either through this
(corporate) MSDN subscription or if my company has an agreement in place
with PSS, which I know we've had in the past.)
Sincerely,
Sunny Gulati / UGS.
"Steven Cheng[MSFT]" <v-sc...@online.microsoft.com> wrote in message
news:21WWDfwR...@TK2MSFTNGXA01.phx.gbl...
Joe Kaplan (MVP - ADSI)
Your description is super-detailed. Thanks for that. I'm guessing that
since you don't have SSL certificates on the DCs (yet; hopefully you'll get
that working), then SetPassword is trying to use Kerberos set password or
NetUserSetInfo. A network trace might help figure out which.
You might try to force to use Kerberos by doing the following:
- Make sure you bind with the DNS name of the DC (NETBIOS name or IP
address will break both Kerb and SSL)
- Add AuthenticationTypes.Signing, Sealing and Delegation to your flags
- Ensure that port 441 is open to your DCs (kerb set password port) from
your web servers
See if that helps or changes the results.
Additionally, I'd suggest reposting your SSL issues in the "server admin"
group, microsoft.public.windows.server.active_directory as I'm sure someone
can get that working.
Best of luck. You seem to be very thorough and I believe you'll get this
working.
Joe K.
"Sunny Gulati UGS" <sunny_gu...@community.nospam> wrote in message
news:u7$4hG0RF...@TK2MSFTNGP15.phx.gbl...
Sunny Gulati UGS
everything under the sun, but I haven't. But I have seen at least some
interesting things. I apologize in advance for the length of this message.
Hint #1. I think I'm successfully getting a good Kerberos Ticket.
Note: no firewalls between the IIS server and the AD server. They are
sitting next to each other in the same rack.
The first thing I did is I tried the additional flags suggested below --
Signing, Stealing, Delegation, and Secure. There was no difference in
behavior.
I tried the forcing Kerberos thing. I enabled both success and failure
logging (at two places: Domain Controllers, and the domain itself). Sure
enough, when I use the full name of the host in the LDAP:// string, i get
different traffic (as logged by Event Viewer) to directory services. The
Event log showed me several of the following event:
Event Type: Success Audit Event Source: Security Event Category: Account
Logon Event ID: 672 Date: 4/22/2005
Time: 2:22:34 PM
User: NT AUTHORITY\SYSTEM
Computer: TCCPERFAD
Description:
Authentication Ticket Request:
User Name: Administrator
Supplied Realm Name: tccperf
User ID: TCCPERF\Administrator
Service Name: krbtgt
Service ID: TCCPERF\krbtgt
Ticket Options: 0x40810010
Result Code: -
Ticket Encryption Type: 0x17
Pre-Authentication Type: 2
Client Address: 134.244.169.154
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
So it seems to be that I'm getting a successful Kerberos login for the
Administrator. Yet, i continued to get an Access Denied error message. [To
note, however: I tried to generate a Event Viewer failure message, i was
unable to do so, so I may not have gotten the event logging turned on
entirely successfully.]
Hint #2. Stack Trace May Give a Clue.
Using a tool called Appsight, i'm able to catch the stack at the time of
the exception, plus any interesting things that happen around it. Up till
the exception, I see this happening. Its a little long, its starting at the
point where the deUsr object for the user is instantiated.
System.DirectoryServices does a lot of background work:
- connection to LDAP occurs for a search
- all user properties are retrieved for the user whose password is about to
be changed
- I get a query to the LDAP server for ObjectClass on that user; it seems to
be successful.
- a Runtime InteropServcies.ComException 800005008
- then various libraries start getting loaded:
stdole2.tlb, adsmsext.dll, tsuserex.dll, ntdsapi.dll, secur32.dll
- another LDAP connection searching for objectclass again. It seems to be
successful.
- open \\.\PIPE\lsarpc and \\.\PIPE\NETLOGON
- a DNS query for TCCPERFAD.tccperf.net
- connection to port 636 (trying LDAP over TLS/SSL)
- loads SCHANNEL.DLL,
- loads SECURE32.DLL
- opens LDAP connection over port 389 --> 2828
- opens LSARPC, and NETLOGON pipes again
- DNS query again
- MSWSOCK.DLL is loaded
- WS2_32.DLL is loaded
- 2 more DNS queries and a load of secur32.dll
- closes LDAP connection 2828
And then boom, the exception happens. "Exception 0x0000000005 <unknown
exception>"
The stack trace at time of exception is:
kernel32.dll, 0x77e649d3
rpcrt4.dll, 0x77c78c7c
samlib.dll, 0x5ccf2254
samlib.dll, 0x5ccf37af
netapi32.dll, 0x71c45c1a
netapi32.dll, 0x71c673c3
adsldp.dll, 0x712e82c6
oleaut32.dll, 0x770fcb2d
oleaut32.dll, 0x770f6109
oleaut32.dll, 0x7713f5ff
oleaut32.dll, 0x770f624d
adsmsext.dll, 0x712b779e
adsmsext.dll, 0x712b3c48
adsldp.dll, 0x712e85d5
adsldp.dll, 0x712e25a3
mscorwks.dll, 0x792b3ccf
mscorwks.dll, 0x792f5823
mscorlib.dll, 0x06000c1b
System.DirectoryServices.dll, 0x0600005d
Teamcenter.Community.dll, 0x06002b1d <--- This is us.
Teamcenter.Community.dll, 0x06002ec0
System.Web.dll, 0x06001223
System.Web.dll, 0x06000f8c
System.Web.dll, 0x06000faa
System.Web.dll, 0x06000f93
dccdxpx9.dll, 0x0600001f
System.Web.dll, 0x06000fa6
System.Web.dll, 0x06000fa5
Microsoft.SharePoint.dll, 0x060001d2
mscorwks.dll, 0x791f5cb7
-----
The same exception is then thrown a SECOND time, but with a slightly
different stack trace:
kernel32.dll, 0x77e649d3
rpcrt4.dll, 0x77c78c7c
netapi32.dll, 0x71c46c6d
netapi32.dll, 0x71c46c24
netapi32.dll, 0x71c51aae
mpr.dll, 0x71bd8221
kernel32.dll, 0x77e41817
advapi32.dll, 0x77ddb19b
ntdll.dll, 0x77f467f9
oleaut32.dll, 0x770efed2
oleaut32.dll, 0x770f6109
oleaut32.dll, 0x7713f5ff
oleaut32.dll, 0x770f624d
adsmsext.dll, 0x712b779e
adsmsext.dll, 0x712b3c48
adsldp.dll, 0x712e85d5
adsldp.dll, 0x712e25a3
mscorwks.dll, 0x792b3ccf
mscorwks.dll, 0x792f5823
mscorlib.dll, 0x06000c1b
System.DirectoryServices.dll, 0x0600005d
Teamcenter.Community.dll, 0x06002ec0
System.Web.dll, 0x06001223
System.Web.dll, 0x06000f93
System.Web.dll, 0x06000fa5
mscorwks.dll, 0x791f5cb7
Microsoft.SharePoint.dll, 0x060001d1
Teamcenter.Community.dll, 0x0600175f
mscorlib.dll, 0x060001ca
After which there's a Exception.System.UnauthorizedAccessException that's
thrown, stack trace:
kernel32.dll, 0x77e649d3
mscorwks.dll, 0x79238b7d
mscorwks.dll, 0x79238b00
mscorwks.dll, 0x79238ab4
mscorwks.dll, 0x7923892b
mscorwks.dll, 0x7923b33d
mscorwks.dll, 0x7923b239
mscorwks.dll, 0x792b1011
mscorwks.dll, 0x792b3d1c
mscorwks.dll, 0x792b338d
mscorwks.dll, 0x792b3413
mscorwks.dll, 0x791d74ce
mscorwks.dll, 0x791dcddd
mscorlib.dll, 0x06000c1b
mscorlib.dll, 0x06000b8d
System.DirectoryServices.dll, 0x0600005d
Teamcenter.Community.dll, 0x06002b1d
Teamcenter.Community.dll, 0x06002ec0
System.Web.dll, 0x06001222
System.Web.dll, 0x06001223
System.Web.dll, 0x06000f8d
System.Web.dll, 0x06000f8c
System.Web.dll, 0x06000faa
System.Web.dll, 0x06000f93
dccdxpx9.dll, 0x0600001f
System.Web.dll, 0x06000fa6
System.Web.dll, 0x06000fa5
Microsoft.SharePoint.dll, 0x060001d2
mscorwks.dll, 0x791f5cb7
Microsoft.SharePoint.dll, 0x060001d1
It is the 3rd exception that actually gets bubbled up as an "Access Denied"
exception. The other two previous exceptions seem to be, umm, somewhat more
serious problems.
===============
So at this point, i'm not too sure what actions I should or could take. I
could:
1. Continue to try to get an SSL connection up, and hopefully a different
set of libraries will be used where this problem will not happen. However,
on Monday, i'm getting switched to a different project.
2. Try to verify that I am in fact getting a good connection to Active
Directory through other means -- try to corroborate the Event Log stuff in
Active Directory with the Appsight trace log that i've typed up above.
3. File a bug with Microsoft, and close the issue as "vendor related" (from
our point of view). This is what I'm guessing this will end up as, with a
workaround for SSL.
4. Ask for suggestions as to what to do or try.
Any further assistance, including suggestions of actions to take, would be
most appreciated.
I'm going to look at this again on monday with a fresh set of eyes.
Thanks.
Sunny Gulati, UGS.
Joe Kaplan (MVP - ADSI)
I'm still pretty baffled. It sure would be helpful to know what object
access is causing the "access denied". I wonder if there is anything in the
LSA audit policy you can enable to get the Access Denied captured in the
security event log?
In any event, there are two things that might still be helpful here. It
would be good to know what the network trace looks like and the value of
System.Security.Principal.WindowsIdentity.GetCurrent().Name is in the
successful attempt from the Windows Forms application and the failed attempt
in the web form/web service.
Also, you might try setting the worker process identity in IIS to something
more privileged like the admin account or SYSTEM to see if that helps.
Best of luck. And hopefully SSL will eventually solve this, even if you
have to move on.
Joe K.
Steven Cheng[MSFT]
Since haven't heard from you, have you got any progress on this issue? Or
does Joe's further suggestions helps?
If there are any further things we can assist, please feel free to post
here. Thanks,
Regards,