Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

  • 0 Votes
    2 Posts
    16 Views
    ?
    The admin tool does not currently add the user back; but you can do so directly in the database; the tables are fairly straightforward. To reinstall, make sure to drop the database after install well. It does not get removed by default.
  • 0 Votes
    3 Posts
    242 Views
    ?
    I had to change 2 things when I had this problem on my windows computers. 1: I could not use the ip-address because of SSL errors - I had to use the host name. 2: I had to make sure that I logged on to the correct port. Your example was 88 in both login and push, but I forgot to use the port in the login command (I was using port 443). Perhaps this will help someone having the same issue.
  • Log in - npm commandline

    Support authentication proget npm
    4
    0 Votes
    4 Posts
    40 Views
    ?
    The URL must still be incorrect; the /npm endpoints will return JSON-based content, where as the errors shown is HTML-based body content (<!DOCTYPE html>...). You can use a tool like Fiddler to see precisely what URLs are being requested, and then hopefully diagnose/trace from there.
  • 0 Votes
    2 Posts
    20 Views
    ?
    Yes, although this is currently extensible by extending the UserDirectory class.
  • Publishing NPM packages

    Support authentication installation ldap proget npm
    3
    0 Votes
    3 Posts
    48 Views
    ?
    Hi Christian, the information you posted had mentioned internal packages (Aeon Framework, etc), so I removed it That said, it wasn't an error message, but a JSON document that contained metadata information about packages. This is an expected response if you visit an API URL directly in your browser, and when the npm client relies on the JSON data. If you are receiving an error from the npm client, please make sure to share: the precise error message that npm client is using the precise URL that the npm client is requesting; you can get this by running Fiddler, and seeing the requests that the client makes Note that you will need to disable Windows Integrated Authentication at the IIS level, not just within ProGet.
  • 0 Votes
    5 Posts
    6 Views
    ?
    I actually am at fault for not being thorough here; I jumped in without being diligent. I am not using Integrated, but using LDAP provider via forms in Buildmaster and it was this that was failing. My apologies! Our custom OAUTH API gateway validates against ADFS prior to providing tokens, think of it as a custom Oauth2 token provider to provide SSO with Windows Auth. The whys and hows can be discussed offline if you want, though there are a few sites which explain this and the reasonings. This custom OAUTH Api/gateway worked at the time of Buildmaster not working. Hence my confusion about why one was working and not the other. With that said, I will still continue to monitor. I will assume this was a "fluke" on the system side that is not worth troubleshooting.
  • 0 Votes
    6 Posts
    28 Views
    ?
    The error you shared was: An error occurred processing a PUT request to {url}: Invalid user name or password. A PUT request is what the NuGet client does to push packages to a feed. You'd want to look for a message related to GET or other requests. But, if you're seeing an unknown, then the problem is likely authentication related, but you'd have to look in the error log, it could be a bad url too... You can always try run fiddler, and attach ProGet to the fiddler proxy server to see precicely the requests that proget is making as well.
  • 0 Votes
    4 Posts
    125 Views
    ?
    i updated to PowerShellGet 1.1.1.0 and it solved my issues. Release Notes PowerShellCore support Security enhancements including the enforcement of catalog-signed modules during installation - Authenticated Repository support Proxy Authentication support Responses to a number of user requests and issues
  • 0 Votes
    6 Posts
    127 Views
    ?
    I was able to get Otter to work with TFS Git on-premises. All I needed to do was set the Otter website and service to run as a specific domain user that has rights to the TFS Git repository. Then in the Raft settings, leave the username and password empty. The Otter code will use the "DefaultCredentials" in LibGit2Sharp., which are the credentials of the currently executing service user. This is slightly sub-optimal, but it works. The next thing I would like to understand is why Git rafts are so slow (going to assets is fairly slow to load, ~10 sec) P.S. I never tried setting the "Basic Authentication" in TFS you recommended, as it is a fundamental change that could affect other users and services.
  • Active Directory Authentication

    Support authentication proget
    4
    0 Votes
    4 Posts
    44 Views
    ?
    Sorry on the slow reply; this is extremely difficult to debug, because it involves a very complex set-up and expertise in undocumented LDAP/AD/NETBIOS conventions, as you might imagine… The problem is that the underlying libraries are returning that useless “server not available” error when trying to lookup the NETBIOS doman name. Here is how that query is constructed. private string GetNetbiosDomainName(string dnsDomainName) { string netbiosDomainName = string.Empty; DirectoryEntry rootDSE = new DirectoryEntry(string.Format("LDAP://{0}/RootDSE", dnsDomainName)); string configurationNamingContext = rootDSE.Properties["configurationNamingContext"][0].ToString(); DirectoryEntry searchRoot = new DirectoryEntry("LDAP://cn=Partitions," + configurationNamingContext); DirectorySearcher searcher = new DirectorySearcher(searchRoot); searcher.SearchScope = SearchScope.OneLevel; searcher.PropertiesToLoad.Add("netbiosname"); searcher.Filter = string.Format("(&(objectcategory=Crossref)(dnsRoot={0})(netBIOSName=*))", dnsDomainName); SearchResult result = searcher.FindOne(); if (result != null) { netbiosDomainName = result.Properties["netbiosname"][0].ToString(); } return netbiosDomainName; } Basically, it’s trying to enumerate all partitions and try to locate the netbiosname property. This is important to do because sometimes a credential will be sent to ProGet in a NETBIOSNAME\username or username@NETBIOSNAME format. The failure could be happening in one of two places (where the Properties collection is accessed), but shouldn’t be happening in either. Any assistance in identifying this would be helpful. We could just ignore this error, and assume that that a failed NETBIOSNAME resolution means the domain name is always the same, but we'd prefer not to just ignore errors like this...
  • Change password for developer

    Support proget user-interface authentication
    3
    0 Votes
    3 Posts
    8 Views
    ?
    Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException
  • 0 Votes
    6 Posts
    55 Views
    T
    As far as I'm aware, the original issue in this thread has been resolved long ago. If there is a new issue with pulling connector packages, please post a new question.
  • 0 Votes
    2 Posts
    6 Views
    ?
    You can install a separate website in IIS that points to the same home directory, which supports forms authentication, then use that separate URL for npm & bower. With a separate IIS site, upgrading won't touch it so it will upgrade as per normal with the installer.
  • Create private feed using npm

    Support proget npm authentication
    2
    0 Votes
    2 Posts
    17 Views
    ?
    Unless something has changed, you cannot use Integrated Authentication with npm because the client doesn't support it: http://inedo.com/support/questions/2647 However, if you enable LDAP authentication in ProGet and then disable Integrated Authentication, you'll be able to use your Windows credentials. If it's the backslash that isn't supported, try the Active Directory provider, which supports the user@domain syntax.
  • Npm feed authentication with api key

    Support proget npm authentication
    5
    0 Votes
    5 Posts
    42 Views
    ?
    Is this feature now available? Where could I find documentation to this?
  • 0 Votes
    4 Posts
    12 Views
    ?
    Thanks for the feedback. The HttpModule was not the cause. I just had to configure the NuGet.config credentials correctly in %ProgramData%\NuGet\Config\NuGet.Config, which is machine wide rather than user specific. I will distribute this configuration to all developer machines using an Active Directory Group Policy.
  • 0 Votes
    6 Posts
    33 Views
    ?
    The upgrade is a coincidence, and the problem could have been triggered by something as simple as restarting the application pool; this is handled entirely by IIS (more specifically, Microsoft Negotiate). Negotiate authentication uses Kerberos (see Kerberos Explained), and this is difficult to debug. You can search for things like “windows negotiate authentication fails” to find all sorts of tips, but this article has been a good resource. In my experience, the most common reasons this doesn’t work: accessing by a different url (buildmastersv vs buildmastersv.mydomain.local) having a time difference between server and domain controller not having certain patches/windows updates NTLM is a different type of authentication, which may not be desirable.
  • 0 Votes
    4 Posts
    8 Views
    ?
    This answer doesn't answer the question. Is there anything else to check or try?
  • Problem authentication (404) with NPM Feed

    Support authentication proget npm
    5
    0 Votes
    5 Posts
    35 Views
    ?
    Ah, I see. We have been able to reproduce this - it looks like a regression in handling the feed-specific npm adduser URL. We've also always handled the /siteroot/-/... one as well because npm used to always use that regardless of the repository URL. I think that changed some time around npm 2.7 when we added the second handler. Regardless, we've already fixed this internally (again), and will be releasing the fix as part of ProGet 3.8.1 likely some time tomorrow. Thanks for the help!
  • 0 Votes
    9 Posts
    133 Views
    ?
    Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc. In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements. Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors). You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)