First off, I'm a newbie at AD; I know how to setup a basic domain, but that's it.
I'm running a hosting service for some Windows Applications. User permissions is based on Active Directory security groups.
Let's say I have Contoso.local as my Forest - the NetBIOS name is CONTOSO. I want to provide a SaaS where clients can sync their Active Directory users and/or groups to my AD while keeping their own NetBIOS name. For example, if I had a client who somewhere on the globe was named Acme and their forest domain was Acme.local and their NetBIOS name was ACME, then I would want John Doe to have the ability of logging into my SaaS as ACME\John.Doe instead of me having to manage all users for my clients and requiring John to login as CONTOSO\John.Doe. The idea here is white labeling.
Immediately, you're probably thinking AD FS, but my SaaS doesn't support Federated Services.
I could set up another domain controller on my network to replicate against my client, but that seems overkill. And, I don't know how to accomplish this.
Is there no way for my AD to simply sync and/or authenticate against another domain's users and groups? (I need groups too, because depending on the security role, a user has access to specific info.) Can I setup a Trust or LDS to accomplish this?
If so, or if not, please provide suggestions. Some how-to's would also be much appreciated!
Thanks,
Joshua
I'm not sure I completely understood exactly what it is you are trying to do, but yes, Federation might have been an answer. Apart from federation, I suppose using forest trusts might be one way to accomplish the objective of letting users log in with their native domain\account names. Just an idea.
Related
Problem statement
I need to make finding all the available active directory groups and their relationships in a tree and forest structure for each an every enterprise application held on an AD Domain Server easy to identify and understand by business user and technical users via an Existing IT Service Request web based application.
What I am hoping to achieve as an outcome is:
Knowledge of an API that I can connect to extract this metadata from and synchronise with the IT Service Request Application
Knowledge of what metadata AD Domain Servers are capable of providing
Knowledge of how to connect and synchronise the meta data from the IT Service Request Web based Application without compromising security
You didn't say which language you want to use. I will assume you will use one of the .NET languages, since that is by far the easiest to interact with AD.
To read the Active Directory Schema, you can use ActiveDirectorySchema.GetCurrentSchema(). That will return a ActiveDirectorySchema object that you can use to read much of the information you would want to know. There are example for how to use it here.
For your 3rd point: to read this data you have to be authenticated as a user of that domain (or a trusted domain). Authentication is already built in. When you use ActiveDirectorySchema.GetCurrentSchema(), for example, it uses the credentials of the current user to authenticate.
I am working on a solution in which we are securing Hadoop echo system and its components.
My use case is I want to Authenticate the user from its AD and these ADs can be multiple. in short, this is a multi-tenant solution and each tenant or customer have their own AD so how can I link OpenLDAP with multiple AD
NOTE: There is no trust relationship needed between the ADs. means a user must authenticate from its own AD not any other.
Assuming you've considered the possible security implications of doing this (i.e. ensure CustomerA cannot adversely impact CustomerB) as well as potential customer unease (I've had to maintain completely separate servers to house different customer directories because clients were uneasy about having the service running their partition on the same machine running some other customer's directory service) ... Referrals should be able to do this -- different OUs in OpenLDAP would refer out to the various AD environments. You may need to configure an option within your application to follow referrals.
Need some help trying to figure out my authentication options for using the embedded service in an app owns data scenario.
Is the only way to authenticate and generate tokens by using your Azure AD credentials? I have went through the examples and got everything running just fine but....
Here at the university that I work at our credentials change every quarter. This means all 10 or so apps where I need embedded reports will have down time as I update this information every quarter. This is going to create a lot of work. Not only that but I really don't like the idea of the rest of the developers on the team managing the code having access to my personal AD account which is tied to lots of other personal university resources..payroll.. etc..
Am I missing something is there not another way to go about setting this up?
Is there anyway to setup a separate membership provider to authenticate against?
Thanks for your help.
Perhaps a service principal is a better approach for you. Instead of using a service account with a username and password you use a secure API KEY instead.
See below link, there are some limitations using a service principal as apposed to a master account:
https://learn.microsoft.com/en-us/power-bi/developer/embed-service-principal#service-principal-vs-master-account
But no, your not missing anything you if you want to use app owns the data model with a master account you'll have to know the username and password and ideally that should be a limited account that only has the access it needs, is not on the same password policy as normal user accounts where its password can expire etc.
I am currently working on a project where i have to make a Hotel Booking Application. There will be general user who will browse through available rooms and will have to login to book. Hotel owners will have account to manage their inventory. And there will be admin section to manage the app. I am confused about what is the best approach to scale this kind of app in Laravel. Because each kind of account will require different type of authentication. I have thought multitennent approach but doesn't seem like This app falls into this category. Thanks in Advance for any help.
For this scenario, you can implement Role based authentication.
You need to create 3 roles.
Hotel Owner
Application Administrtor
General user.
Based on the role, you need to provide access. If you haven't developed Authentication system, you can use Entrust along with Confide.
Entrust provides a flexible way to add Role-based Permissions to Laravel4.
Confide is an authentication solution for Laravel made to cut repetitive work involving the management of users.
Written an app that grabs info of a specific computer using WMI remotely. Currently, I have to auth on each computer using one of the machine's local accounts. What I would like and what I'm trying to do is to be able to auth using a domain account (one of the accounts on the AD domain controller machine).
Right now, I can auth to domain machines only with local accounts with the exception of the domain controller. I can log on the AD DC using domain accounts by using NTLM protocol. The piece that isn't working is thus logging on to domain machines other than the DC using domain accounts.
Is this a code-issue or is it an AD setting issue, like I need to instruct the domain machines to always check with the DC when a user auths or something?
I'm using System.Managemnt.ManagementScope class in C# to handle all this curerently. Any help would be much appreciated.
I'm quite the newbie when it comes to AD and domains.
EDIT: Solved it.
The Active Directory account in use needs to be given the permission called "Trusted for Delegation" in order to work on computers other than Domain Controllers. This right is extremely powerful, effectively allowing your account to present itself as any other account on the domain.
The alternative is to pass explicit permissions to the process. Bear in mind, though, that when connecting to another computer via WMI, the process created on the remote computer will not be able to authenticate to other computers on the domain; this is considered 3rd party delegation. There is a workaround to this limitation created by Frank White (on SO).