Jump to content

Recommended Posts

Posted

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

Posted

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

Posted

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.

 

Posted

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.

Posted

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

Posted

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?

 

 

 

Posted

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

 

Active_Directory_Domains.jpg

Privileged_Account_Credentials.jpg

Posted

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

Posted

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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...