trexman Posted March 2, 2021 Posted March 2, 2021 Hello, we are running Passwordstate without any problems. Now I got the task to add user accounts from an external AD (outside of the Passwordstate server domain) I did as Administrator the setup of the Domain under Administration -> Active Directory Domain (with the check mark at Used For Authentication) I created Privileged Account Credentials under Administration. The check of the Privileged Account returned "Username and Password matches". After that I did the "Add From AD" under Administration -> User Accounts. Here I could search for the user accounts in the newly added domain and add them without any problems ...so far so good. But If I try to login with an user account of the new domain it would not let me through. I tried different login spellings and also Web Authentication Option for the user without success (for the Web Authentication Option I only tested AD Authentication ones...) The Error Console is empty. Where is the problem? Or how can I debug this further? Thanks for your help. Trexman
support Posted March 2, 2021 Posted March 2, 2021 Hello Trexamn, From your Passwordstate web server, can you please check you have functioning DNS to this secondary domain, and confirm no firewalls are blocking access either on 389 or 636? If using LDAPS (636) and a non-trusted domain, have you followed our instructions for importing the Domain Certificate? Regards Click Studios
trexman Posted March 3, 2021 Author Posted March 3, 2021 Thanks for your reply. Just a question to so that I don't misunderstand you. Quote From your Passwordstate web server, can you please check you have functioning DNS to this secondary domain What do you mean with "functioning DNS to this secondary domain"? Yes, I can ping and resolve the Domain Controller FQDN from the Active Directory Domain settings. The DNS Server for the Passwordstate server has a forward Conditional Forward to the DNS Server of the second domain. There is no firewall blocking between the Passwordstate web server and the Domain Controller FQDN of the second domain. I verified this with telnet and a small tool called LdapAdmin from the Passwordstate web server to the second DC. I also did you use the non SSL port - 389... Is there some kind of debug logging for the login part? Thx.
trexman Posted March 3, 2021 Author Posted March 3, 2021 One additional thing. I just did a tcpdump on the firewall. Should there be any "activity" between the Passwordstate web server and the second domain controller during a login attempt? I could not track anything. If I do the Password check in the Privileged Account Credentials windows, than I see packages between the 2 servers.
support Posted March 3, 2021 Posted March 3, 2021 Hi trexman, When you say "it won't let me through", is it reporting an error, or just saying Username or Password is incorrect? For authentication, we do not use the domain controller you've specified in the field 'Domain Controller FQDN' - we communicate to the base domain you have specified on the screen Administration -> Active Directory Domains. We have had one customer previously believe we are communicating directly with the domain controller here, and they were doing DNS/Open Port tests against the Domain Controller FQDN, instead of doing it against the base domain. Can you confirm what you are testing here? Thanks Click Studios
trexman Posted March 4, 2021 Author Posted March 4, 2021 Hello, Quote When you say "it won't let me through", is it reporting an error, or just saying Username or Password is incorrect? Yes sorry for my imprecise answer. You type in user name (domain\username) and the password. After that the password login prompts again, like you put in the wrong credentials. I don't fully understand what you mean with "against the base domain"? Do you have an example how the setup should look like for such a case? (meaning how to authenticate Passwordstate against a second domain?) I can only test DNS/LDAP against a server (DC) or am I wrong? Or do we maybe have a misunderstand in how our environment is setup. Let me explain this shortly: We have one AD domain. Let call it contoso.local. This is our main domain where the Passwordstate server is a "normal" member of it. Now we have a second AD domain from a customer that is connected via VPN to our network. Lets call it customer.local. There is no connection between the 2 AD domain. But the Passwordstate server can reach the customer DC through all ports via IP or DNS name. Our goal is, that either user of the domain contoso.local or customer.local can authenticate at the Passwordstate portal. Right now I see had imported successfully all user from both AD domain. But the Browser authentication fails. Is the problem maybe here explained? Can't Passwordstate "split and direct" the login authentication to the corresponding DC on the basis of the Domain in the username field?
trexman Posted March 4, 2021 Author Posted March 4, 2021 Here are the screenshot of what I configured to the example above. Of course this won't work because of the name. And yes, I check the field under Active Directory Domains with the commands "set userdomain" and "set userdnsdomain" like it is mentioned in Passwordsate But that should not be the problem, as we have successfully imported all user of the domain customer.local
support Posted March 4, 2021 Posted March 4, 2021 Hello, Can you please provide a screenshot of what you mean by " login prompts again"? If this is your browser prompting you, and not one of our login screens, then it sounds ilke you have Anonymous Authentication for our site in IIS disabled. Can you check this? By enabling this, it might help with your authentication promblems. Regards Click Studios
trexman Posted March 4, 2021 Author Posted March 4, 2021 Yes, thanks. That was the problem. Anonymous Authentication was enabled for the server but not for the passwordstate site. Mea culpa Now I get a form login instead of the login windows. Have a nice day.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now