User seen as a Group

Stephen.Schaff

This is an example screenshot of one of my permissions lines:

It has three "system account" type users on it. But one of them (SA-RestrictedAuto) is seen as a "Group". I can tell because the background is purple and all of my other groups have a purple background.

Normally I would not care, but the permissions for this user are not working. When I go to the "Test Privileges" button, the SA-RestrictedAuto user is shown as having no permissions on any feeds (while SA935001 works as expected).

I use active directory integration for my user list, and I thought this might be an issue with how that is configured. But I could not find the configuration for the ProGet integration with Active Directory. I looked in the Admin page, the files on the ProGet server and in the ProGet database. The admin page as a place to change it, but not to view it.

What do I need to do to get this user's permissions to work?

atripp

@Stephen-Schaff is SA-RestrictedAuto also a group? It's possible in AD to have a User and Group have the same name.

There is (or was) an issue in our products where adding privileges will favor the Group when both a User and a Group have the same name. I'm not sure if it's been resolved, but @rhessinger might be able to confirm it.

The issue is related to the UI more than anything, and it can be worked-around with a "database hack", by changing the PrincipalType_Code from G to U in the Privileges table for the appropriate entry.

Stephen.Schaff

While I can change the db table, I would rather not. I looked through my Active Directory tree as best as I can and don't see any groups setup as SA-RestrictedAuto.

How does ProGet decide if an Active Directory entry is a User or Group?

I am assuming it has an Active Directory query of some kind. With other products, we have had to provide that query as part of configuring the product. But I don't see any such configuration with ProGet.

I feel that if I knew how ProGet decided if an entry was a group vs a user, I could update my active directory to make it think it is an actual user.

rhessinger

Hi @Stephen-Schaff,

@atripp is correct. There was an issue previously that would ignore the specified type of a principal and favor a group, but that has been fixed for a bit now.

One thing that can still happen is accidentally selecting a group versus a user when adding a permission or restriction to a task. Currently, we just present the list of users and groups in the order they are returned from the domain. If a user and a group are using the same name, it may be difficult to decipher which one you are selecting.

Can you please tell us what version of the InedoCore extensions is installed? Also, can you please verify that you are using the Active Directory (LDAP) user directory?

Thanks,
Rich

Stephen.Schaff

@rhessinger, thank you for looking into my issue.

I did a search in my Active Directory for my user (SA-RestrictedAuto), and regardless of what I searched on, I only ever got the user back. I don't think that there is a group with the same name in the our Active Directory.

Can you please tell us what version of the InedoCore extensions is installed?

I have version 1.10.1 of the InedoCore extensions is installed.

Also, can you please verify that you are using the Active Directory (LDAP) user directory?

I am not sure what you are asking here. Do you want to know the path to my user in my Active Directory tree? If so, it is side by side with another user that is working fine. So I doubt that is the issue. (But I can send the path if you really think that will help.)

If you are asking for how ProGet is setup to integrate with my Active Directory, then I would love to know how to see those settings. As I indicated in my original question, I cannot find the ProGet settings for integrating with my Active Directory anywhere. (I would REALLY like to know where these settings are stored so I can verify that they are correct.)

rhessinger

Hi @Stephen-Schaff,

Thanks for confirming the extension version for me.

As for the user directory question, if you navigate to Administration -> Change User Directory Did you configure and select Active Directory (LDAP)? We previously had a configuration for a user directory called LDAP or Single Domain Active Directory (now called LDAP or Single Domain Active Directory (Legacy)). I wanted to verify you are not using an old LDAP implementation.

Thanks,
Rich

Stephen.Schaff

@rhessinger,

I went to that page and found:

I clicked the "Advanced" option and found the Active Directory Settings. (Wahoo!)

When I click on LDAP (what it says I am using in the first screen shot), I appears that I am indeed using LDAP or Single Domain Active Directory (Legacy).

Looking around in there I found some test options. The test options all seemed to indicate that my user was found as a valid user:

To test it a bit more, I looked up a user that does not show up as a group (i.e. it works fine), and it seemed to be similar to my broken one (SA-RestrictedAuto):

The person who setup ProGet at my company told me that it was a lot of work needed to get ProGet to work with both integrated windows security (IWA) and basic authentication (when needed). We actually run two instances of the site, one that uses IWA and one that uses basic authentication. (Though they share the same backing database.)

This is fairly complicated and as such I am hesitant to change any of these settings. (Though I can do so with a good plan and a scheduled downtime.)

Stephen.Schaff

This reply is in addition to my previous reply from today.

I have noticed that users that were once working as users are now being added as groups. For example, user SA9350001 is now be added as a group. (I had not noticed this before because it is an active user and I could not remove it from the permissions it was already setup with.)

In this screen shot, "all feeds" has had SA9350001 setup for a while and is listed as a user. But today I added SA9350001 and it was added as a group.

We recently upgraded ProGet to Version 5.3.21 (Build 24). This issue started occurring right around that time. We were a few versions behind when we made the upgrade. Have there been changes to Active Directory integration in the last few versions of ProGet?

Note, as I said before, we use the Legacy active directory integration. Though I looked at the "non legacy" one and I cannot see how to make it work. It seems to not have the needed settings (to map user names and email addresses).

atripp

Is SA9350001 also a group?

The change that @rhessinger mentioned only impacted the "new" active directory, though there may have been a change in ProGet that happened. Do you remember what you upgraded from? It'd be easier to find on this long list ... https://my.inedo.com/proget/versions

Otherwise, can you elaborate on this?

I looked at the "non legacy" one and I cannot see how to make it work. It seems to not have the needed settings (to map user names and email addresses).

We hadn't found anyone using custom field mappings, and only a small handful of other products even support the ability to use custom fields (Windows doesn't), so we didn't add it...

So I wonder if it would "just work" after all

Stephen.Schaff

There may have been a change in ProGet that happened. Do you remember what you upgraded from?

I think my previous version was 5.3.12. Were there changes made to the Active Directory integration between 5.3.12 and 5.3.21?

So I wonder if it would "just work" after all:

I did try to setup the Active Directory style of integration and it did "just work" as far as finding users. (I don't understand how, but I am impressed).

However, I did notice that it displays users with my domain on the end:

While the one I use now does not:

Is that going to cause issues when logging in from command line tools like docker and nuget? (We have not purchased additional licenses for sandbox testing of ProGet, so I have no way to test it out besides switching over to the new style and hoping that it does not bring down all of ProGet for my company.)

Stephen.Schaff

Edit to my previous response: The previous version I had installed was 5.3.15 (not 5.3.12 as I had indicated).

rhessinger

Hi @Stephen-Schaff,

This should not affect anything. If you are using a single domain (did not use multiple domains in the domains to search input), the domain does not need to be appended to the username. So your existing command-line tools should not be affected.

If you also need to be able to prepend your domain (ex: domain\user), I can send you some documentation on how to configure it. The previous login formats of username and username@domain.local will still work, but it adds the ability for domain\username. A small disclaimer though, the domain\user functionality is still in testing.

Thanks,
Rich

Stephen.Schaff

@rhessinger @atripp

I tried to swap out the user directory this morning and it failed horribly. We could not get ProGet back to a working status and had to restore from backup.

Is it possible that we could explore the cause of this user account bug a bit more?

Where there changes between 5.3.15 and 5.3.21 that could have caused my users to show up as groups?
Not all of my users show up as groups. Just the ones that are not normal users (Service Accounts and Test Accounts). They are in a different spot in my Active Directory tree from the normal users. Could something have changed to expect users to be in a specific spot in Active Directory?

atripp

@Stephen-Schaff if you're using the legacy directory (i.e. not the one Active Directory (LDAP) one), then there were no changes to that, or anything that uses that code, that would yield behavior like this

There were a lot of non-functional changes to the Active Directory (LDAP), namely that we made a upgrade to which version of the Microsoft libraries we are using. A few users of these libraries with legacy features from ancient (i.e. Windows 2000) domains have reported some problems. Maybe you're describing a such problem?

Because it's obviously impossible for us to reproduce these oddities, we have a debugging tool available, but it requires Visual Studio to compile/run at this time: https://github.com/Inedo/inedox-inedocore/tree/master/InedoCore/AD.Tester

Not sure if that's helpful though.

Stephen.Schaff

Is there a process for us to get back to version 5.3.15? While I want the features of the later versions, we need permissions working again.

Is there a way we could rollback to version 5.3.15 from 5.3.21?

NanciCalo

@Stephen-Schaff

I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries.

You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12