Check Access Test in MMC snapin gives "Incorrect function"

Aug 26, 2010 at 9:10 AM

After starting creating item definitions and Item Authorizations I wanted to use the Check Access Test menu option.

I try this and it brings up my login name (minus the domain part) in the Windows User part by default.

I click on Start Check Access Test and I it appears to work ok.

I use the elipis button to select a domain user account (one that I have added to my Item authorizations).

In the Select User dialog I select a domain user, use the Check Names and its all ok.

Click on the OK button and I get an immediate "Incorrect function" dialog response.

It does say users can be selected only from a Windows Server 2003 machine and we are using Windows server 2008 machine for our domain controller.

I would be surprised if this is a real issue. Selecting users for Item Authorizations works fine.

I have tried putting my own domain account as per pattern 'account@domain.xx.xx.xx' and I get an immediate 'Incorrect Function'

Is there a problem with Windows Server 2008 or is there some permission that I need to set before I can test another user account.



Aug 26, 2010 at 10:47 AM

Instead of press “choose” button, try to manually write the username in the form username@fullUPN.ext.

I think there was some mistake on your domain with the “default UPN Suffix” name resolution.



Andrea Ferendeles
NetSqlAzMan Project Coordinator
E-mail Web

Aug 27, 2010 at 1:59 AM

Hi Andrea

I have tried the full domain name

I have tried (for myself)

They all fail with 'Incorrect function'

The only one that works is

  • he00273 (which comes up by default)

If I try another user's account  or domain account I get

'Incorrect function'

With respect to

>> I think there was some mistake on your domain with the “default UPN Suffix” name resolution.

I am not sure what you mean.

How can I check to see what this is set to?

(If this is Control Panel -> System Properties -> Computer Name Tab : Domain, then this is set correctly)

I did a SET in CMD.EXE and got this (only part captured)

USERPROFILE=C:\Documents and Settings\he00273
VS90COMNTOOLS=c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\

I am using fully qualified names and that is not working, unless the application is applying a default UPN suffix to my fully qualified names.

If I use a simple account name it still fails.

It was all coming together beautifully until this glitch.




Aug 27, 2010 at 3:57 AM

I have found one work around (although its a pain)

If I use RunAs with the NetSqlAzMan MMC shortcut I can specify another user.

However I have to make that user a member of NetSqlAzMan_Administrators to see the the stores and applications.

I can then run the Check Access Test  on that user.

It seems that if the  Check Access Test  is using Kerberos Protocol Transition (KPT), then it is not working here.


Aug 27, 2010 at 4:19 AM
Edited Aug 27, 2010 at 4:26 AM

I enabled event logging and got entries like this in the security event log when I tried to use another user account

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Date:  27/08/2010
Time:  11:06:06 AM
Computer: FB20562
Logon Failure:
  Reason:  An error occurred during logon
  User Name: 
  Logon Type: 3
  Logon Process: C
  Authentication Package: Kerberos
  Workstation Name: FB20562
  Status code: 0x80090302
  Substatus code: 0x0

For more information, see Help and Support Center at

My workstation is XP Pro SP3 (we will be moving to Win7 when they update our SOE) and the DC is running on Windows Server 2008.

There seems to be several hotfixes for this issue (0x80090302) but the most promising targets Vista not XP. is for Vista not XP.




Aug 27, 2010 at 5:37 AM

I tried using Kerberos Protocol Transition in code and it generated an "Incorrect function" exception

            //var ApplicationCheck = new CheckAccessHelper(cs, WindowsIdentity.GetCurrent());

            WindowsIdentity otherUser = new WindowsIdentity("");
            var ApplicationCheck = new CheckAccessHelper(cs, otherUser);

            //AuthorizationType authorization =
            var cando =    ApplicationCheck.CheckAccess(CheckAccessHelper.Operation.Create_New_Case);


The new WindowsIdentity call failed on an "Incorrect function" exception

Stack Trace is

System.Security.SecurityException was unhandled
  Message="Incorrect function.\r\n"
       at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type)
       at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName)
       at SecurityAzManTest.Form1.button3_Click(Object sender, EventArgs e) in C:\Projects\SandBox\SecurityAzManTest\SecurityAzManTest\Form1.cs:line 110
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at SecurityAzManTest.Program.Main() in C:\Projects\SandBox\SecurityAzManTest\SecurityAzManTest\Program.cs:line 18
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()

The problem appears to be a Kerberos rather than a NetSqlAzMan issue.

The problem is how does one fix this?

I can't be alone using a dc on win server 2008 with XP Pro SP3!!!


Aug 27, 2010 at 7:53 AM

Read here:

Kerberos Protocol Transition works on Windows Vista/2003 or later only !

Not Windows XP !

I have not asked you … but I was sure you are on Vista or later OS … sorry.



Andrea Ferendeles
NetSqlAzMan Project Coordinator
E-mail Web

Aug 27, 2010 at 8:08 AM
Edited Aug 27, 2010 at 8:10 AM

Ok Thanks

I would guess that the NetSqlAzMan MMC snap-in the way it checks another domain user using 'Check Access Test' uses the Kerberos Protocol Transition (KPT).

Inwhich case it won't work with XP!

I suppose it would be too hard to prompt for a password and use impersonation if the KPT fails.

I use Windows 7 Ultimate at home. I am not sure when work will catch up to the rest of the world. I think it is planned but its subject to budgetry constraints.

I can always write a simple application for known test accounts where I know the password to run the mmc NetSqlAzMan snap in under that accounts credentials.