I’ve got a server at a client setup in a test domain. Let’s call it domain a. We want to allow several test users to access the application for testing purposes. They are in domain b. There do not appear to be any trust relationships between domain a and b. The application uses windows with. I don’t have admin rights to anything in either domain there.
Questions:
is there a way to allow a user from domain b into our application easily?
Does a trust relationship need to be setup between the two domains to get anything to work? I think so, but I don’t have the authority to do this so getting this done is going to be really hard.
TIA.
Wally
Related
We have an app that let our users use their own domain to access our platform.
For example, if our website domain is "abc.com", we allow our user to use their own domain (for example "external.net") by setting this domain to point to our server.
To achieve it, we need to set their domain each time in our "Google Console"(/Microsoft) so that the authentication (we do have a login of course) will work with their domain as well...
The thing is that we think maybe we could accomplish such a result by just forcing all our users to use our main domain (abc.com) and just after they log in, we will redirect them to their domain.
It will save us the time to add each time their domain to "Google Console"(/Microsoft).
The question is if it's something that we really can do, or google will disallow such auth if which user comes from A domain, and will use B domain with the token he got from A domain.
*If such a thing is not allowed, is it allowed by using my subdomains? like user1.abc.com / user2.abc.com etc... without having to fill those subdomains in the provider console (Google/Microsoft).
I hope the question is clear enough,
Thanks!
A note about verification of your applicaiton.
In order to have this application verified you are going to to Verify your site ownership for every domain listed as a redirect Uri or a JavaScript origin.
So the only way that is going to work is if you can prove you own those domains. By registering them in google search console.
I currently have a web config file in a web service that is using the following code snippet so that it can access resources on Sharepoint
<identity impersonate="true" userName="[domain admin]" password="[password]"/>
Clearly this situation is not a good idea and we are currently replacing this with the correct way of doing things. However, in the mean time we are creating a new domain user that is NOT the domain admin and using that as a stop gap. The domain admin was used as people were too lazy to determine the right security levels required and a domain admin will be guaranteed access to every resource.
My question is: What is the minimum level of security that this domain user requires in order to continue accessing the Sharepoint Web Service? What sort of things should I be thinking about?
What web service are you talking about exactly? SharePoint web services are permissions aware, just like any other module, so it is different if you want to say read items or create a site. You need to know first what you are trying to accomplish and then give the user the exact permissions to do that
When running Sharepoint (WSS 3.0) with Windows Authentication (NTLM), external users must supply their usernames in the form of DOMAIN\username. This makes sense, because you could have multiple domains, trusts between them, etc. However in my case, I only have one domain, and I want my users to be able to logon with their pure username only. Is there any way to configure Sharepoint with a default logon-Domain to get this to work?
Changing the authentication to basic or forms is not an option for me.
That's a windows/IIS issue rather than something specific to sharepoint.
You can find a more detailed explanation at http://forums.iis.net/t/1151401.aspx but basically it's impossible due to the the design of integrated authentication - the client has to know the domain before the server is contacted.
The closest you get to a default domain is local logins on the server - potentially a solution if users are truly external.
Realize that some browsers can be configured to automatically provide NTLM credentials. For example, IE can do this. I believe by default it will for sites in the Local Intranet and maybe even for Trusted sites (if not, you can change it so it will).
There is software out there for pushing these settings (policies) out to users if their computer is a part of your domain.
I've got a problem where I have a .co.uk domain of which I am the registrant but my web developers control the domain via easyspace.com. I'm not using the web developers anymore and it ended on bad terms so I would like to change my domain to another registrar without getting them involved. Does anyone know how I can do this?
Thanks
In order to do anything with your domain, you need to be a registered user for it. for every domain, there 4 types of registered user:
Registrant/Owner
Administrative Contact
Billing Contact
and Technical Contact
If you do a whois look-up of your domain name you can see if you are one of those registered users.
If you are, you should be able to contact the Registrar of record (i.e. GoDaddy, Network Solutions, GKG, etc.) and gain an account control login if you do not already have a login for them.
Once you have an account, you can change the Name Servers thereby pointing your site to a different server than it is currently, or initiate a transfer to a new registrar (which costs money - typically the price of a 1 year registration)
Tell them to give you control of it. You're not asking them to do something for you, you're just demanding them to hand over what's yours (assuming the domain is yours).
If you own the domain name, you should be able to change the information with the registrar to point it at another hosting service or your own.
Change your domain host to point to a new name server that you control.
You may lose your web site code but can always start a fresh.
If a company often requires users to be created in a partner's active directory, and vice versa, does it make sense to set up a federated / trusted relationship between the AD instances? If so, what should be considered? Does the ACL for users in the partner AD still work the same way? What security risks does this expose?
Thanks!
KA
Update:
I've learned that there's a better way to do this by having the application itself check user stores. The best way to do this is by moving the application into a domain trusted by both user stores. I've provided more detail in my answer below.
I've been researching this a bit more, and I've found a good solution. Since both companies both need to use the same system, the system itself just needs to verify if a user exists in either of the user stores(authentication), and then to the authorization at the system level.
The idea behind giving both companies access is solid - If we are working together and didn't have a way to do this, we'd need to re-create all the users from the company without access in the connected user store. Obviously, this would be a total mess and a maintenance nightmare.
I found out that in my case, even though both ADs are on the same WAN, it's necessary to have a formal federation or trust. Thankfully, we already have a domain that's trusted between both companies, so I just have to move the applications used by the partners into this domain. After that, it's simply a matter of fully-qualifying the DNS suffix to indicate the AD being used. Application-specific ACLs then reference the desired user store.
Yeah, it makes sense if you want both to be able to authenticate people across mulitple domains. You have to put the server that has the application you're targeting in a domain trusted by every AD instance you want to use for authentication.