I am having some trouble and need some help. I am trying to connect a website to authenticate to Active Directory through LDAP using DNN.ActiveDirectory, but I can only get the "Check Root Domain" portion to pass. Using ldp.exe on the server I am able to connect to the domain controller and query the users on it with the same user name and password I am trying to use with the plugin, and even using my domain admin account makes no difference. I have tried it with every authentication type, changing the root domain (only way that would get the check root domain to pass is the LDAP://domain.local), with/without the domain in front of the username, and with/without the default domain filled out.
I don't have access to the error logs at the moment since I am not at that office yet, so I will get those posted when I can. If I remember correctly the error being logged was an authentication error. LDAP initially wasn't configured on the domain controller so I had to set that up, and admittedly I am not too familiar with it so I followed this guide: https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362. I am using the default ports. I stopped before setting up LDAPS, but when I couldn't get that to work I continued through up to the signing the certificate part. I was working on getting the certificate signed when I came across notes that DNN.ActiveDirectory doesn't support LDAPS. My tests with successful connections using ldp.exe were all against port 389. Are there some extra configurations that are needed to get DNN.ActiveDirectory working that weren't covered in that guide, or any common snags I should be aware of?
DNN.ActiveDirectory has not been maintained for a while, and does not support LDAPS afaik - see Checking Root Domain step fails.
My recommendation is to have a look at AD-Pro Authentication.
Related
I have a question regarding SQL Server Reporting Services 2019:
We have received a HTTPS-certificate and added a URL for both Web Service and Web Portal. When we try to access either /Reports or /ReportServer on HTTP we can get through with no problem, but when we try to access on HTTPS then we are met with a logon dialog which will give three attempts at log on before displaying a white page. All attempts at entering a valid combination of user name and password returns a 401 error.
We've tried removing and reinserting all bindings for HTTP, HTTPS, SSL, changing logon mechanism in the config file to use Kerberos, NTLM or a combination of those but nothing works.
Does anyone what the source of this problem might be and how to solve it?
We figured out what the problem was. Authentication issues did not behave the same for HTTP and HTTPS. My test user wasn't a member of the correct user group. Once we gave it "System User" access then we could log in.
We have 2 domain in salesforce:
1-) https://gablesinsurancerecovery.my.salesforce.com
2-) https://gableinsurancerecovery.force.com
and we have 2 user:
developer#cloudspade.com
communitytest#cloudspade.com
developer#cloudspade.com mail work with success on 1. domain but not work on 2. domain.
Likewise, communitytest#cloudspade.com mail work with success on 2. domain but not work on 1.domain.
Its not a problem. Problem is:
2.domain is important to us. Because we have a react-native project by forcereact and we want work with community domain. ( 2. domain ). We setup with successfully this link: https://www.youtube.com/watch?v=9zxMUrayFZ8&t=1634s
We was work with perfectly with the video in the link for login.salesforce.com or 1. domain but doesn't work for 2. domain.
Error is:
error image
As seen in the photo we was see a page. But our expectation was that it would working we send redirect_uri. The redirect_uri we sent was to return "girApp://success" with an access_token and instance_url at the end. But we encounter a screen as you can see in the photo. Redirect is not working. Our goal is to access the access_token with redirection within the application after login and authorize.
Lots to unpack here.
***.my.salesforce.com is your main domain, for internal users. ***.force.com is for Customer/Partner Experience Cloud (formerly known as Communities, formerly known as Portal).
developer#cloudspade.com mail work with success on 1. domain but not
work on 2. domain
Out of the box Salesforce is perfectly fine with internal users logging in to community or even 1-click switching over from internal SF to community. Collaboration and all that. Your administrator probably marked only certain profiles / permission sets as community members, you'd need to check config. But it's possible to use the community login page, you guys just chose not to.
communitytest#cloudspade.com mail work with success on 2. domain but
not work on 1.domain
Yes. Community members must use community login page. They can't use generic login.salesforce.com, test.salesforce.com or your branded ***.my.salesforce.com
works perfectly with (...) login.salesforce.com or 1. domain but
doesn't work for 2. domain
That's because most of the time the community login url must be full. Just the domain might not be enough for login because you can have up to 100 communities under same domain. You probably saw the example when you were enabling communities (Setup -> Digital Experiences -> Settings)
Go to Setup -> Digital Experiences -> All sites and write down the url you'll see there. It'll probably be something like ***.force.com/myportal. That means that for API login you might have more luck with ***.force.com/myportal than ***.force.com.
Stop reading this answer now and go read Sitecore - How to get User ID if the user was logged in using external identity provider (Salesforce SSO). Play with that OpenId Heroku app, once you get this to work with community user in the browser - you'll know which url to put in your react app. React developer might "like" this link too: https://gablesinsurancerecovery.force.com/.well-known/openid-configuration
It's kind of written in this article's footer: https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_endpoints.htm&type=5
Instead of using login.salesforce.com, you can also use the My Domain,
Experience Cloud site, or test.salesforce.com (sandbox) domain in
these endpoints. For hostname, use the My Domain, Experience Cloud
site, or custom URL
I used the DCOS 1.8.8，and applied arangodb 3.1.3 on it. When I set the jwt-key and make the authentication works. I meet the following problems.
1.when I open the web site: http://master.mesos/service/arangodb3, I need to fill the user and pasword, however the password for the "root" is not null. I wonder what's the user and password, and how can i get a available one?
2.when I used the coordinator address instand of the master.mesos, and I enter the web UI, then changed the root's password. what's the amazing thing is that the password I set is not work with the web site(used the master.mesos as Web UI).Also the CLUSTER panel doesn't show well（No data~ in total).
Both ArangoDB and DC/OS are using the standard HTTP Authentication header. Under the hood ArangoDB Authentication is working fine however the reverse proxy that DC/OS is using will not forward any authentication down to arangodb. That is why you can't log in into ArangoDB through the DC/OS whereas it will work from inside the mesos cluster.
This is the reason why you have to manually enable authentication via the extra args and there is no simple checkbox for this :( It is simply not supported right now and not really useable.
I have two domains pointing to same server, what i am trying to do is when i log in into the application using domainOne.com the session is maintained for that domain , if i try to access the application from other domain domainTwo.com the session is not there.
I want the same session values in both the domains,
I have PHP application [Yii Framework Application], and the requirement is, one third party application wants part of my application content that needs to be authenticated. I authenticate the content using SSO(Single Sign On[JWT]) and pointed their domain to my content(which needs to be shared) using this way, i am able to login using their's(Third party's) domain but when i access the same section using my original domain the session is not there (No Session when using My domain).
What i want is, when i log in using their domain and access the content from my domain it should show me as logged in user
Conditions -
domainTwo.com/someContent - Logged in using this
domainOne.com/someContent - Session is not here
and vice versa
P.S someContent is in my server only.
Please can anyone help?
Thanks in advance..!
edit - Requirement is the client dont want iframes, please suggest methods which dont use iframes.
We have our own web server hosting our website that is open to the public outside of our network.
I have a request to make our "Internal Postings" link on our Careers page to authenticate the user against our network's Active Directory list.
I currently have it setup so the link hits a page inside the directory structure of the website, and this page's folder is set to "Integrated Windows Authentication". Anonymous access is turned off for this page. If the user is authenticated (ie: logged into our network or supplies proper credentials) it passes them on to an external careers website which hosts our job postings. If they fail to authenticate, it displays a custom 401 error page.
This works fine, but there is a problem with it. Using IE, people cannot just enter their username. They (of course) are required to enter the domain name as well. Unfortunately the default 'domain' is set to the URL of our website (www.xyz.com/username). I would like it to automatically choose the name of our internal domain (aaa/username) but am unsure of how to do this.
Another option would be to use LDAP and a little ASP scripting to authenticate the user. I have this code already, but am unsure of the security consequences of doing so. Basically, the page will be setup for anonymous authentication, and if the user isn't logged into our network, they will be prompted for a username/password using standard textboxes. This is then passed to an ASP script that does an LDAP lookup against our Active Directory. Is there any security issues with this method?
Which method would you choose to do?
Thanks.
EDIT: It seems I cannot authenticate to ActiveD via LDAP using a username/password combo. So forget about that option.
My question now is, how can I change the default 'domain' that IWA uses? Is that at all possible? IE seems to default to 'www.xyz.com\username' (my website) rather than 'aaa\username' (my domain name). Of course, www.xyz.com\username fails because that is not where our ActiveD resides... Is this possible? I want to make it as simple as possible for our employees.
You cannot authenticate an user with a script that looks up the user in LDAP. You need to know that the user is who it claims it is, and the only way to do that is to let NTLM/Kerberos authenticate the user (ie. establish proof that the user knows a secret stored in the AD, the password).
The URL of the web site to the set of sites considered be in the local intranet zone for IE browsers running on the internal network. By default sites consider to local intranet will be sent the current logged on users credentials when challanged with NTLM/Kerberos. Hence your internal users shouldn't even see a network logon box.
I hate to dredge up an old thread, but the answers are a bit misleading, if I understand the question. The thread Remus refers to is about authenticating via LDAP with a username only. As he points out, that isn't possible. But it looks like what Kolten has in mind is authenticating via LDAP with a username and password both. That's a standard practice called binding.