Jump to content

tburke

Members
  • Content Count

    34
  • Joined

  • Last visited

  • Days Won

    1

tburke last won the day on May 21

tburke had the most liked content!

About tburke

  • Rank
    Advanced Member

Profile Information

  • Location
    Washington State, USA
  1. tburke

    Update failure, permisions?

    This was helpful, thank you!
  2. We are in the process of testing in place updates using the update mechanism within PasswordState. In our test environment, when I tried this, it fails and it looks like it's because the service account doesn't have access to those files. I think that is what is going on. I ran the manual installation described in the manual which I had to go into services and shut down the PasswordState service then I could copy the newly downloaded file in place, then restart the service. I thought maybe it was just that I was on an older version and maybe the update mechanism maybe had a bug but when an update came out last week I tried it again. The update mechanism seems to be having access (and I'm not sure but I think it's because of the service account from what I can tell). Before I do the update manually again, is there anything you can think of that I can verify permission wise, setup wise that might be causing our problem. We are currently one build back at the moment. Thanks!
  3. I've got a setup question we are trying to figure out. Possibly a licensing question too. For the pasword reset portal, does it matter how many actual portals we have setup, is the license based on number of users? For example, say we have a 1000 user portal reset license and we already have an internal password reset webserver setup on the inside...but it's not reachable from outside our company network. I'm thinking I could throw a second reset portal in our DMZ, allow that 443 traffic in from there to our passwordstate server inside our production network. Can I run two reset portals like that and still use my 1000 user license for both if those are the same user base? What I want to avoid is having to have all our internal users have to go outside, then route back in if they have a password reset they need to do. If they are inside, they would route to our inside reset portal...and if they are remote, they could get in through our dmz setup reset portal. Does that make sense at all or is this a bad idea for this setup?
  4. tburke

    Additional Domain Setup

    I just read that post again. So to be clear, it wasn't blanking out of the filter that worked for me, it was adding the: When I added this to the domain setup, I was able to query security groups without getting an error message saying user wasn't valid. adserver.domain.com/cn=users
  5. tburke

    Additional Domain Setup

    Sorry, I thought I replied to this earlier today. So that did work for me. I was able to query some security groups from PasswordState into our secondary domain with that filter applied. Thank you! I'll let you know if we hit on any other issues. I'll be setting up the remote site in that domain. Got some other stuff I got to get done so might be a few days before I can get it fully deployed out and tested. So it kind of sounds like our common denominator here was the "untrusted" part in that second domain maybe.
  6. Checked with my coworker and looks like it's the same result as we where seeing before.
  7. tburke

    Additional Domain Setup

    When doing a security group details search query I see this in the debug information box. I'm using a user from that secondary domain here and I've tested to make sure that it's a valid user.
  8. tburke

    Additional Domain Setup

    Is there any extra documentation or advice you could give to help me debug a domain connection issue. I've added a secondary domain to our main PasswordState server and it's setup nearly the same as our main domain which seems to work fine ( LDAPS - Port 636). Just need some help trying to figure out from PasswordState's point of view to debug this. This is what I've tried. We have opened up the 636 LDaps port in our firewall. Looks like the port is listening and I can touch it. Verified that from my PasswordState Server, I can run Test-NetConnection to the secondary domain: PS C:\Users\Tburke> Test-NetConnection -ComputerName <fqdn here> -Port 636 ComputerName : <fqdn here> RemoteAddress : 192.168.1.20 RemotePort : 636 InterfaceAlias : Ethernet0 SourceAddress : 192.168.0.10 TcpTestSucceeded : True Used the Windows ldp.exe to make a connection to the secondary domain. (works) The next thing I tried was downloading the open source LDAP Admin app and connected again on port 636 with an AD user from the other domain. I was able to see OU from this tool and make the connection. So where do I go from here to trouble shoot this in PasswordState? I didn't see much in the web log and nothing came up in the error console. I'm trying to figure out what I might try next to debug this? In Passwordstate when I try to add a user from this secondary domain, I get this displayed:
  9. We got the same results when installing with an Administrator account.
  10. Ok, so all API keys throughout PasswordState at the system wide settings take priority....but again, no way to reduce the exposure to just the "System Wide API Key" alone. I'd love for that to be added to a future release if possible. It's the one key that has access to everything it should be limited access by default.
  11. Just an example, our is different but same format. I didn't want to expose our internal workings too much on this web forum. It's more like "mypud.org". My co-worker is ran it this way but hasn't verified. Normally the way our IT department deploys software out through SCCM and it's usually done as the System user I believe.
  12. So our current setup is one server setup as the main passwordstate server, lets call it https://password.halox.net. Then we have another machine setup for the reset portal called https://passwordreset.halox.net. In the config ini we pulled this out of it so we are putting the reset portal like the following. [SETTING] CP_TEXT=Password Reset/Unlock Account CP_URL=https://passwordreset.halox.net So what we are seeing is as soon as the CP is placed on the client box, the prompt changes to show the reset link which we expect but instead of our domain name of say "halox" it's "haloxnet". Where would it be getting this information from? When CP get uninstalled it back to it's normal working domain name on the login prompt. The version of Windows 10 we are using is 1709 Enterprise 64bit if that makes any difference.
  13. I believe I'm using the current version. Passwordstate Build Number : 8556 Browser Extension API Build Number : 7676 Mobile Client Build Number : 8150 Password Reset Portal Build Number : 8501 Remote Site Locations Build Number : 8361 The problem we are seeing in the Reset Portal is only after the installation of the portal's windows cred provider is installed (Windows 10 Enterprise), we are seeing an issue where now every time the user goes to log in, instead of our domain, it now replaced our domain name with extra naming for example, "halox" now becomes "haloxnet" (the period is missing). This causes all log in attempts to fail because there is no "haloxnet" domain. Is this a setup issue on our side or is this a bug in the credential provider? Silent Install msiexec /i "passwordstate_CPx64.msi" /qn CP_TEXT="Reset Password/Unlock Account" CP_URL=https://passwordstateportal.halox.net /quiet /norestart
  14. That part was a bit confusing to me on the Administration tab, in the "System Settings" in the "API Allowed IP Ranges"...when I add say one IP address to this list, the one machine I want to be able to allow "Anonymous API" key, does that mean I have to white list every password list API to include other machines access to those passwordlists? From a passwordlist "api key & settings"...it sounds like from "note 3" that if I limit that "Anonymous API" key access I limit all of my passwordlists to those addresses specified in the system settings. There isn't a specific way to not allow the "Anonymous API" then...is there? It's just that " ?QueryAll´╗┐" that scares me and I don't want any machine to have access to that particular Anonymous api key. Or, does Note 3 mean only if the "System Wide API Key" is being used, if normal API key for the list or winapi for that passwordlist will work just fine. I'm hoping it's that but just wanted to be sure. Note 1: You can specify ranges in the format of 192.168.1.*, 192.168.*.*, 192.*.*.*, 192.168.1.1-192.168.2.254, or you can specify individual IP Addresses such as 192.168.1.50 Note 2: Specify one IP Address or range per line Note 3: If making a call which retrieves data from multiple Password Lists (System Wide API Key), no data will be returned for this Password List if the IP Address is invalid Note 4: You can also set Allowed IP Ranges for all Password Lists from the screen Administration -> Passwordstate Administration -> System Settings -> Allowed IP Ranges tab
  15. I might have found the answer. It does appear by using the normal API using the "Anonymous API" using the " System Wide API Key " specifically gets those passwordlists without having to be a viewer of those lists. I was hoping to restrict who could export those passwords by user and I was hoping by IP as well just to lock it down further. When using the System Wide API, I haven't found how to restrict that like you can the individual password lists. I've got an idea, maybe put the system wide key in a passwordlist, restrict the list to my one user and IP to get the API key. Sort of mixing both the winapi and normal api there but feels a bit of a hack but might work. It feels like that system wide api shouldn't be left on so maybe I'm not realizing the correct way to accomplish this?
×