Azure Active Directory (Azure AD)

“Connecting to site failed: ‘.’, hexadecimal value 0x00, is an invalid character.”, when trying to connect to SharePoint Online

Reading Time: 3 minutes.

This was a peculiar case! A cloud-based “service account” (in quotes, since it’s really just a non-personal user account) on a tenant with ADFS enabled started suddenly getting this error, while running console programs configured as scheduled tasks.

Connecting to site failed: '.', hexadecimal value 0x00, is an invalid character.

Cause of the error

Table of Contents

Okay – so I found a reason for the issue, and a solution, but I’m not sure about the underlying cause for the ridiculous error message. I do have a guess, though!

In this case, we didn’t get very much debugging information from the customer, and since the error was thrown on a SharePoint Online site instead of On-Premises, we didn’t get server logs either. That’s ok – educated guesses are still possible!

The client had ADFS in use, and their configuration had On-Premises AD server taking priority in the login process. However, for cloud-accounts ([email protected] – in my example below, [email protected]) the authentication is supposed to happen against the Azure AD (since that’s where the account is actually located in).

However, since the local AD took priority, it was supposed to manage redirection to the AAD for the authentication. In browser, this works – but within a programmatic solution (such as shown below), this process fails with that peculiar error!

public virtual bool CheckCredentials(string url, string username, SecureString password)
	using (var ctx = new ClientContext(url))
			var credentials = new SharePointOnlineCredentials(username, password);
			ctx.Credentials = credentials;

			return true;
		catch (Exception ex)
                        // We end here, with "ex" containing the puzzling error message
			return false;

It seems to me, that with ADFS in use, the local AD redirected the authentication request to AAD, which probably returned some meaningful error in response (since the password had expired), but the local ADFS was expecing to get response data as XML, and failed to handle this response (due to a mismatch of the response type, or whatever other reason).

For SharePoint’s Client libraries, this error was returned instead of the original one. My guess is that the original one was omitted by the local Active Directory.

Speculation, I know! But at least the solution below worked for me.


The fix for me was simple. The password for that “service account” (again, in quotes for a good reason) had expired. Since nobody ever used it for logging in (it was just used for the tasks), nobody had gotten any password changing prompts.

Does this apply to you, however? Easy to find out!

To investigate the issue, try logging into Office 365 using your account and password. There’s a fair chance, you’ll be presented with this:

Azure AD's prompt for changing an expired password in Office 365
Azure AD’s prompt for changing an expired password in Office 365

In our case, the issue was fixed after the password was changed and updated to the Credential Manager on the computer running the tasks.

If this didn’t help you, it could be something else too. I found a few pointers about issues with certain Exchange configurations, for example. I’m leaving these useful links for your reference here:

0 0 vote
Article Rating
Notify of
1 Comment
most voted
newest oldest
Inline Feedbacks
View all comments