Proget Integrated Auth Mixes Machine Name with User Account

arozanski_1087

Product Version: Version 5.3.15 (Build 2)
Extension Version: 1.7.10

rhessinger

Thanks for sending that over. I took a look into the code and checked some things and I don't see anything that would look up the computer name. Can you look at the [Privileges] table in the ProGet database? Do the usernames include the $ in there also? Also, do you have any sort of reverse-proxy sitting in front of ProGet?

Thanks,
Rich

arozanski_1087

No Reverse-Proxy in front of my server.

RE: [Privileges]

My account is the only account in this user domain that I have explicitly specified, and it has a $ in the name.

Other data fields for my entry are as follows:

| PrincipalType_Code |  Role_Id | Feed_Id | PrivilegeType_Code | UserDirectory_Id |
|G                   |    4     | NULL	  |  G 	               | 6                |

I'm going to take a wild guess and assume then that the PrincipalType_Code value means group account, as actual user accounts show up with code U, and the actual group accounts which contain the users I want to have in the various roles also show up as G.

rhessinger

Hi @arozanski_1087,

You are correct. G is for group or gMSA. The only thing that makes sense is that your AD has a group or a gMSA for your user account with the same name and it is return the group first. You could manually change the DB record to remove the $ and that should then work. But that is an annoying manual step. Can you please verify that the user you are testing with does not have a Group of gMSA named as AROZANSKI$ in AD?

Thanks,
Rich

arozanski_1087

@rhessinger absolutely. my IT team tells me no, and I am in AD looking at the account via Active Directory Users and computers and I do not find anything. I can confirm without a doubt that there isn't a gMSA for this user.

rhessinger

Hi @arozanski_1087,

I apologize for all the back and forth I'm struggling a bit to recreate this issue. I have even tried to just add a computer by searching it by name and I still cannot recreate this. Would you be able to perform a test search in the Advanced Settings of your Active Directory provider? Does that also return the computer accounts?

Thanks,
Rich

arozanski_1087

My searches were all done in the advanced search window, and that did not return computer accounts. I also tried in active directory to just look up computer accounts (instead of users) and couldn't return any.

rhessinger

Hi @arozanski_1087,

I think I may have finally tracked this issue down. Would you be able to manually install the Inedo Core 1.7.11-CI.1 extension and see if that fixes your issue? There is one spot that does not properly apply the user and group filter upon saving and I'm thinking I may have fixed it.

Thanks,
Rich

arozanski_1087

Trying to install it, but it causes this error when I load the web portal:

[InvalidCastException: Unable to cast object of type 'System.Byte[]' to type 'System.String'.]
   Inedo.Extensions.UserDirectories.Entry.ExtractGroupNames() +260
   Inedo.Extensions.UserDirectories.ActiveDirectoryUser.IsMemberOfGroup(String groupName) +120
   System.Linq.WhereArrayIterator`1.MoveNext() +71
   System.Linq.Buffer`1..ctor(IEnumerable`1 source) +492
   System.Linq.<GetEnumerator>d__1.MoveNext() +116
   System.Linq.Buffer`1..ctor(IEnumerable`1 source) +281
   System.Linq.Enumerable.ToArray(IEnumerable`1 source) +90
   System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory) +87
   Inedo.ProGet.Web.Security.TaskChecker.FindPrivilege(IUserDirectoryUser user, ScopedTask& scopedTask) +42
   Inedo.Security.UserContext.CanPerformTask(ScopedTask& task) +162
   Inedo.ProGet.WebApplication.Security.WebUserContext.IsAuthorizedForTask(ProGetSecuredTask task, Nullable`1 feedId) +199
   Inedo.ProGet.WebApplication.Pages.RootPage.CreateTopPanel() +1006
   Inedo.ProGet.WebApplication.Pages.<CreateChildControlsAsync>d__2.MoveNext() +871
   System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31
   System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60
   Inedo.ProGet.WebApplication.Pages.<InitializeAsync>d__10.MoveNext() +621
   System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31
   System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60
   Inedo.Web.PageFree.<ExecutePageLifeCycleAsync>d__46.MoveNext() +234
   System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31
   System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60
   Inedo.Web.PageFree.<ProcessRequestAsync>d__45.MoveNext() +240
   System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31
   System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60
   System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +59
   Inedo.Web.Handlers.AsyncHandlerWrapper.EndProcessRequest(IAsyncResult result) +33
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +648
   System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +213
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +131

I've rolled it back by deleting the .upack file i added to the /Extensions folder and restoring the one I had put in the recycle bin, but I'm still facing this error.

rhessinger

Hi @arozanski_1087,

Did you restart IIS or the Integrated Web Server after copying the upack file back? Also, did your upack file have a version number in the name? Or was it just InedoCore.upack? I doubt this, but can you navigate directly to /administration/extensions? Could you also take a screen shot of the files in the Extensions folder?

Thanks,
Rich

rhessinger

Hi @arozanski_1087,

You can also try flipping back to the Built-in User Directory by reseting the base admin account. You won't lose any AD users you have setup, it just simply switches ProGet to use the Built-in directory and resets the Admin password back to Admin.

Thanks,
Rich

arozanski_1087

I restarted both the service and the IIS webserver after I rolled it back. When I found that did not fix the issue I kicked the OS entirely.
My upack file name that I installed matched what you had me download off of that feed.
Extensions Page in the UI:
Extensions folder on the VM:

rhessinger

Hi @arozanski_1087,

Glad a reboot of the OS fixed it. Can you try renaming the downloaded version to InedoCore.upack. I noticed ProGet gave me some issues installing the extension manually when leaving the version number on there.

Thanks,
Rich

arozanski_1087

@rhessinger --
I did forget to add: I was able to resolve it all after I reset the admin password and reset the services. Once logged in It prompted me to clear cookies for my name account since I am the only one that's been using it.

I have done ask you asked in your last reply. It looks as though renaming the file to just be InedoCore.upack is the solution.

I have since logged back into my instance of Proget and re-enabled LDAP using an administrative service account. From there, it sent be back to the login, where I logged in as myself. In the Permissions page for users and groups, I have added a user in the directory where the users reside, and can confirm that his username does NOT get replaced with his MACHINEACCOUNT$ object. Testing on a few other users seems to indicate that the issue is solved.

Thank you very much for your help.

rhessinger

Hi @arozanski_1087,

That's great! I'm sorry it took this long to get this working. Thanks for working with me to figure this out! I'm going to make a change to the documentation right now to include the requirement of naming the extension file. I will also get a full release of this extension out today so it will lock in that version with the ProGet release tomorrow.

Thanks,
Rich