Posts made by Stephen.Schaff

OK. I made the addition to the NETBIOS mapping section.

I mistakenly believed that if the test functionality worked out, that it was setup correctly.

I would recommend a feature/fix so that if the NETBIOS mapping is needed, that it will fail in the Test section of the User Directory window. Because the User Directory Test functions worked fine without the NETBIOS mapping, I thought it was correctly configured. Finding out that it is not correctly configured only after the User Directory switch is done is a less than desirable user experience.

A strong disclaimer or a change would help the user experience there.

I am going to try the change again on Friday.... Fingers crossed!

I am going to try to change the user directory to Active Directory again. (I will request an hour down time this time to ensure there is no lost work.)

Before I do it, I would like to get your advice on the things that went wrong.

COM ERROR: Your repsonse to this one seems good. If this happens again, we will reboot and then set the "Load User Profile" to true.

USER NOT FOUND: Your advice on this one is confusing. You suggested that we just login with user name and password. I had indicated in my first post that we had done that (when we browed to the instance of ProGet that users basic auth). But we still need the integrated security to work. (Or is that somehow not supported with the Active Directory user directory?) How can we fix the User Not Found issue once we log in using Username and Password? (Leaving it so that all users have to always log in with a username and password is not a solution we want to go with.)

LOCKED OUT: This is really the same as the User Not Found issue. We were not fully locked out. We could login with username and password when we went to the URL that is hosted using basic auth. But windows integrated security was not working. We need a way to re-enable that once we switch to the Active Directory user directory.

@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?

I changed my User Directory this morning in an attempt to work around this bug: https://forums.inedo.com/topic/3164/user-seen-as-a-group/11

I went from an "LDAP or Single Domain Active Directory (Legacy)" User Directory to an "Active Directory (LDAP)" User Directory. Before I switched, I setup the new User Directory to have the same permissions as the old one. I also used the test features in the "Active Directory (LDAP)" User Directory settings page to look up users and do searches and it was working fine.

After I switched, browsing to the ProGet homepage redirected to this:

(We run two instances of the site, one for integrated security, and one for basic auth. The basic auth site kept working fine.)

When I logged in on the basic auth site, running a user search test in the settings page showed this:

We logged into the proget server and restarted the services. We also attempted to use the "clear authentication cookies" option, and ran in Chrome's Incognito Mode. Nothing we could do would fix the error.

So I set the User Directory back to the original "LDAP or Single Domain Active Directory (Legacy)" User Directory. (I figured we could research it more when we did not have users being locked out of the system.)

But when we set it back, the error did not go away!

We tried all the same things that we did after the first User Directory swap (restarting services, clearing cookies etc). Nothing we did worked! We were stuck. And now our down time was stretching even longer.

Fortunately our policies have us do backups of the database and snapshots of the server. We did a restore from back up and it started working again.

We then had to send out the embarrassing email letting everyone know that any auto builds that ran for the last half hour have to be re-run.

This was embarrassing to me. Having it continue to fail when we put the setting back was really bad.

What went wrong? Why did it do this in the first place, and why did it not start working when we put it back?

A few more details:

• After we switched back to the ""LDAP or Single Domain Active Directory (Legacy)" user directory, tests on the "Active Directory (LDAP)" User Directory worked again. Meaning that the COM errors were no longer there. Here is an example of how that looks:

• Here is an image of one of the entries on the Event Log for the service:

• When we first switched, the error message (first screen shot above) said that the name of the User Directory was 'Queries the current domain, global catalog for trusted domains, or a specific li'. That seemed odd since that was not the name of the "Active Directory (LDAP)" User Directory we had switched to. (I double checked that we had switched to the "Active Directory (LDAP)" User Directory.) The directory name was the same as the type of the user directory:

• When we switched back, error message (seen above) correctly had the name "LDAP" for the User Directory (though it was still broken)

• We are running ProGet Version 5.3.21 (Build 24)

OK, I did a bit of looking around and ProGet is currently very well priced compared to its competitors. I can easily buy two servers of ProGet for the price of single a JFrog license.

If needed, I could try to use that to convince my Management to purchase a second production license for use as a Sandbox instance.

My current issue (User seen as a Group) requires me to "Change User Directory" and fully swap out the permissions of my ProGet server. From the old LDAP legacy option, to the newer Active Directory option.

But Active Directory Integration is not available in the free version of ProGet. So I am stuck making this change in production, hoping that it does not cause an issue for Nightly Builds (I will try it at night).

Or I have to try to talk my boss into another license of ProGet. One that will sit unused 80% of the time. It is hard to get a request like that approved. It makes management wonder why we use a product with licensing like that. Most of our other products include sandbox instances for free or at a significantly reduced price. (Since it is understood that you are not using it for the actual purpose of the product, but just to enable smooth configuration deployments and upgrades.)

We use ProGet for a lot of things. It is embarrassing for me to have downtimes with ProGet due to a configuration error, because so many developers depend on it. When the work day is done, many nightly builds startup and also need ProGet to run successfully.

This means it is really hard to make configuration changes to ProGet at a time that does not cause issues for someone. This is normal though. All systems have this.

But most systems offer an instance that can be used to test out configuration changes, prior to deploying them to the real server. This allows deployment with confidence. Without this I am testing out configuration changes right on my production ProGet server (that all my Developers use).

However, it is hard to get approval for another production level license of ProGet because it is known that it will sit unused the vast majority of the time. (Between configuration changes.)

This request is to have Inedo consider the possibility of offering another (cheaper) Tier of pricing for a instance that is only for sandbox/configuration testing use. Meaning that it can't be used by developers or autobuilds (or any other use where real packages are downloaded for real use). I would recommend it only be available to those who also purchase a normal license (to prevent abuse).

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

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.)

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).

I think I have an idea of what is happening here. I think that this issue is actually caused by my other open issue: https://forums.inedo.com/topic/3164/user-seen-as-a-group

I noticed that when I am adding any service account user, it is added as a group instead of a user. Actual users do not have this issue. In fact if you look at step 4 in my reply on Feb 12th, you will see that the restriction added shows the user as a group (purple background).

Lets suspend this issue until the we have figured out the issue with users being added as groups.

@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.)

@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 thank you for looking into this for me.

I am using ProGet Version 5.3.21 (Build 24).

It is running on a Windows Virtual Machine.

Here is the Publish Packages task:

Thanks again for your help!

Here is a step by step repro of what I did:

1. Add my user (SA9350001) as a Publisher and Viewer:
   
   
2. Test Permissions for my user:
   
3. Add a restriction for my user:
   
4. Ensure that the restriction was added:
   
5. Check permissions again:
   

I would expect the Feeds_AddPackage to be removed from the list.

NOTE: The only other spot that SA935001 appears on the Tasks screen is a Publish Packages grant for a feed called ESP-NPM. But as that is only on that one feed, I did not expect it to interfere with the deny.

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.

I looked into this a bit with one of my impersonations that was working fine.

When I do a docker login with a username of "api" and the api key, it works just fine. When I looked at how mine was setup compared to yours, I noticed that you have your user listed "email style". (CMSProxy@YourDomain.com). Mine just has a username (no @domain.com).

Curious, I added my domain to mine to see what would happen and when I did I got the following error:

error parsing HTTP 403 response body: invalid character '<' looking for beginning of value

This seemed similar to what you got, though I also got a lot of HTML that you did not get.

Still, it might not hurt to try using the actual username (as defined in your LDAP) instead of the email address. It is very likely just CMSProxy. (If you have already tried this, then I apologize for adding noise to this conversation.)

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?

I have a user that I want to have permissions to all feeds except one (or maybe a few).

I thought that the option of "Add Restriction" would allow me to setup an "All Feeds" permissions, and then a Restriction permission (in permissions systems, a deny usually overrides an allow).

But it did not work as I had hoped. Here is what I did:

• Picked a user that already has "Publish Packages" and "View & Download Packages" permissions to all feeds.
• Ensure that this user does not have any admin or manage feed permissions (or any other permissions in any other permissions grouping)
• Add a restriction for the user to one feed.
• Opened the "Test Permissions" feature and entered the user and the feed.

As I said, it did not change the permissions for the user. (They still had full publish and view permissions.)

I am really hoping that I do not need to add each feed to my user. (As new feeds are added, keeping up with that will be tedious and error prone.)

Is there a way to give a user access to all feeds except one or two?

Not sure if this is intended, but I thought I would report it.

An anonymous user (or a user with no permissions) can click on the "Packages", "Assets" and "Containers" links at the top of the ProGet homepage and see a listing of the respective items.

I would assume that a user that did not have view feed permissions would not be able to view a list of the packages and which feeds they are in.

@apxltd

I like the idea of baking the concept of a base image into the build layer, though I see a few issues with it (one of which, from reading the document, you may have dealt with already).

The first is that the Dockerfile is usually thought of as the source of truth for the container build. Any configuration that is setup in the auto build should look at the final container image layer in the Dockerfile (so you get the real one if it is a multistage file). It could allow the user to select from any history of that container image as the "base" image. But just selecting any base image could put the selection at odds with the Dockerfile.

BuildMaster seems to have a "we will build your Dockerfile for you" feature. Which is fine until you need some complicated stuff in the Dockerfile that is not supported as a feature.

The second part is that this only works for developers that know about it and want to follow policy that says to use it. From an operations standpoint, more surety is needed. ProGet is where containers are pulled from for operations. If there were no way for a container image to get into a feed without it inheriting from a "base" container image, then we know we can trust that at least our images are from approved sources.

I think that when this becomes a "Must Have" for me, I will see if I can meet the need with a web hook.

Either way, I appreciate you taking a look at the feature request.

Requested Feature:
Have a "Inheritance" check for a Docker Feed. This setting would point to another Docker Feed (lets call it the "Base Images" feed). When a container is pushed to a docker repository ProGet checks to see if it has the Inheritance check setup.

If it does, then it calls docker image history on the container that was just pushed. This will list the IDs of the container images that were used to create the recently pushed image.

ProGet will then check list of image IDs returned, comparing them against the images in the "Base Images" feed. If the pushed image does not have one of the images from the "Base Images" feed in its history, then it was inherited from a non-approved source, and the push is blocked.

Reason for Feature:
Many companies want to control the containers that get used in their systems. However this is difficult to do without overly limiting development.

This feature would allow a group of "blessed" containers to be created and placed in a highly restricted feed. Then allow other container feeds (with more permissive permissions) to contain any container as long as it is inherited from a "blessed" container somewhere in its history.

This allows operations teams to know that there are not rogue containers with bad dependencies being put up for deployment.

I have a docker feed that I need to get the container image IDs for. Using the docker command line tool I can only pull containers that I know of, but I need a list.

Is there an API call that will enable me to list the container images (and their container ids)?

Thank you for the response and the incredibly fast fix!

I will get my instance upgraded and test it out.

Thanks again!

I am trying to enable the feature of Semantic Versioning for Containers.

I did the following steps:

1. Create a new container feed.
2. Select the Manage Feed option from the new feed.
3. Select the Configure option in the Tag Versioning row.
4. This dialog appears:
   

This is where I am stuck. It seems like I should be able to change the Mode option, but there is nothing there to change.

How can I turn on Semantic Versioning for Containers?

I am running Version 5.3.18 of Proget.

Thank you for your response.

I would suggest adding even more details. I would suggest adding at least one example in each bullet point of what kind of actual functionality is altered by choosing that value.

After posting this I found through testing that when the feed is set to "Validated/promoted packages", that the option to upload a package via the UI is removed. This assists in preventing direct additions to a feed that should only contain packages from a promotion pipeline. (Though this can be bypassed via an curl command for Helm charts. I don't know if other feed types allow a similar bypassing of the UI restriction.)

Adding a similar entry for "Free/Open Source packages", along with the one you indicated about "Private/Internal packages", would improve the documentation with more clarity.

The documentation is fairly light on what actually happens when you select one of the "Feed Usage" options when creating a new feed.

For me, I see two options when making a Helm Chart feed:

• Private/Internal packages
• Validated/promoted packages

The documentation lists two others (maybe they are not available in my ProGet build of 5.3.18):

• Free/Open Source packages
• Mixed packages

The docs say to not used Mixed Packages, so I am not really interested in that one.

But I would like to know what selecting the other ones causes to change in the application.

For example: The Package Promotion page indicates that you should choose "Validated/promoted packages" for package promotion, but it does not indicate if it is for the source or target feed. Nor does it indicate what features will be available as a result of this setting.

What functionality depends on this selection? What will change when I select one vs the other?