Access was denied, invalid on the domain

Jun 19, 2009 at 3:18 PM

I really want to use this library, but so far I'm not having any luck. For every connection attempt, I get "Access was denied because the username and/or password was invalid on the domain", 691. I know that the user name and password are correct. I've also wrapped RAS myself (not as completely as this library, though) and am currently using that. I don't get those errors with my version.

Any suggestions would be greatly appreciated!

Coordinator
Jun 19, 2009 at 3:55 PM

How were the credentials being pushed to the dialer? If they were stored in the phone book entry I could very well see that being a problem if the stored credentials were old and you weren't providing them to the dial method.

Jun 19, 2009 at 4:12 PM

I am dialing like this:

RasDialer.DialAsync( new System.Net.NetworkCredential( CurrentSelectedSite.RemoteAccess.UserName, CurrentSelectedSite.RemoteAccess.DecryptedPassword)

Coordinator
Jun 19, 2009 at 4:19 PM

What kind of entry is it? VPN, Dial-up, etc.

Also, is there anything special about the entry like the use of certificates that would cause it to be a non-standard connection? Passing credentials into the method override anything that's been stored in the phonebook so I know that isn't the issue.

Jun 19, 2009 at 4:39 PM

It's just a regular dial-up entry. The systems I am dialing into are Window NT and 2000

Coordinator
Jun 19, 2009 at 5:00 PM

Hmm, what about the domain... from what I can see you aren't passing that to the connection. Is the domain supposed to be included?

Jun 19, 2009 at 7:07 PM

I am dialing from a system on a domain, but the systems I'm dialing into are stand alone. I remember running into this issue when I was wrapping some parts of RAS, but I don't remember where the problem was.

Coordinator
Jun 19, 2009 at 7:43 PM

I think I might know what the issue is. This is from the Windows SDK on the szDomain field on RASDIALPARAMS:

"Specifies a string that contains the domain on which authentication is to occur. An empty string ("") specifies the domain in which the remote access server is a member. An asterisk specifies the domain stored in the phone book for the entry."

Unfortunately the NetworkCredential object will always return an empty string even if you pass a null reference into the property or constructor. Check your implementation of the RASDIALPARAMS structure szDomain field. More than likely you're passing NULL in there rather than an empty string which might causing the problem you're seeing with DotRas.

Jun 19, 2009 at 8:12 PM

Is there a way I can change the domain in the DotRas library?

Coordinator
Jun 19, 2009 at 8:41 PM

We need to confirm that's the problem before we do anything to fix it. If it is the problem I'm going to upset a lot of people by removing the NetworkCredential from being used there, not to mention lose a lot of security all because of some idiotic decision by Microsoft.

Grab the source code, and remove line "parameters.domain = credentials.Domain;" from the InternalDial(NetworkCredential,bool) method in the RasDialer.cs file and try the component out again. I'm fairly confident that's what's causing the problem you're seeing.

Let me know what you find. Thanks!

Jun 19, 2009 at 9:41 PM

Apparently NetworkCredentials.Domain defaults to an empty string. I tried passing "" as the domain in the NetworkCredentials constructor and commenting out the line you suggested, neither worked.

Coordinator
Jun 19, 2009 at 9:48 PM
Edited Jun 19, 2009 at 10:15 PM

Hmm, the only way I can think of to find the problem is to look at your implementation of RAS, copy down all the settings in the RASDIALPARAMS and RASDIALEXTENSIONS structures you're passing into RasDial and put the information here after changing any sensitive information. The issue has to be what is being passed into the RasDial method, if the credentials wasn't the problem I can't imagine what is.

Oh and I have my IDE opened now, the line that needed to be commented was 435.

Edit: If you don't want to post the data here you can compare them yourself and let me know what the differences are. The dialing for RasDialer is done inside that InternalDial method you looked at earlier.

Jun 19, 2009 at 11:10 PM

It turned out to be my problem. I was trying to update the phone number using RasEntry.Update(), but it wasn't updating the entry because of some strange trash data alternate numbers (which I don't use). So, I was still dialing into an old phone number. I'll let you know if it crops up again.

Also, does your library use the notify icon? I've now noticed that even though I check "Show icon in notification area when connected", after updating the entry, it's no longer checked.

Coordinator
Jun 20, 2009 at 2:20 AM

"It turned out to be my problem. I was trying to update the phone number using RasEntry.Update(), but it wasn't updating the entry because of some strange trash data alternate numbers (which I don't use). So, I was still dialing into an old phone number."

Well there was a problem with alternate entries and Microsoft's poor implementation of that API as described at the top of the discussions page. It can cause problems with dial-up entries specifically because they can use alternate numbers. Their API was using the sizeof(RASENTRY) when allocating memory for the alternate string of numbers rather than the size field on the RASENTRY instance passed into the API. I already reported and had them fix the bug, but who knows when that'll get taken care of. The only thing I can say about that problem is to make sure you're using version built for any platform(s) you intend it to be ran on using the preprocessor directives defined on the home page. It makes it a bit of a headache, but that's the only thing I could do to fix the problem other than hard-coding all the struct sizes into the assembly.

"Also, does your library use the notify icon? I've now noticed that even though I check "Show icon in notification area when connected", after updating the entry, it's no longer checked."

There is a known bug in 1.0 that the Options property wasn't being retrieved by RasGetEntryProperties when the struct was being copied to the object. I already fixed the problem for the 1.1 build if you get latest from the source code tab. Here's the work item if you're curious: http://dotras.codeplex.com/WorkItem/View.aspx?WorkItemId=7839

I'll probably be releasing 1.1 soon to get the issue resolved, I just have to finish up adding support for prerequisite entry dialing on the RasDialer component first.