We have an application that uses AD LDS (ADAM) which contains a extended user class ( custom attributes, specific to our application).
One of our clients wants our users linked to their domain users (AD).
When they create a user in their system, a user on our side has to be created. When they delete a user on their system, the corresponding user should be deleted on our side. The same with basic properties (name, email, ...).
The application specific attributes will be modified by our tool.
What is the best or most reliable way to keep those users in sync? The client does not allow us to modify their schema.
I was thinking myself to create a webservice to add/ delete / modify a user on our side which kan be called from within their system. But Maybe there are better solutions.
Thanks.
Personaly I will use ADAMSync for that. You can a kind of 'how do I' in Synchronize ADAM (or LDS) with Active Directory Domain Services.
ADAMSync.exe and ADShemaAnalyser.exe are part of the binary installed with ADAM.
In the case you are affectively using ADAM, be careful to install the ADAM SP1.
You can use the free Identity Integration Feature Pack from MS to sync selected attributes between AD and AD-LDS. You can download it here http://www.microsoft.com/download/en/details.aspx?id=11149
I'm not sure if it supports server 2008. It may be included in server 2008 as a role now.
Related
I work for a company where we started to share the PowerBI license for users without the Office plan. They started asking us to give them access to the Outlook to be in touch with newsletters and other reports from PowerBI. Our organization is not allowing to supply an Office license to PowerBI users.
I have a few questions :
Is there a chance to forward emails to their private mailboxes without converting them to SharedMailbox?
if I add a PowerBI license with Office plan and convert it to shared the PowerBI will be disabled on that account? If not is it possible to take it off or do I need to convert it to the regular mailbox to take it off?
I know about Mail Flow rules, are they safe to use? They are global rules either way.
I am excluding here a Contact user with one reason PowerBI license cannot be added to a Contact user.
Thanks for any suggestions
Found an answer,
Create AD account synch it with O365 move it to correct OU,
go to the user created earlier -> Attribute Editor -> Attribute: targetAddress add: SMTP:youraddress#something.com
Wait to synch and test. All emails should be redirected to the target address without having the license.
We have an application where we store users login name in the format domain\username. We authenticate via windows and then get additional info from our database by matching the domain\username we get from the user to our database.
Now they want to move to the cloud. We authenticate users via apps in Azure AD. However, the user identifier we get back is first.last#domain.com.
I have fiddled around with https://graph.microsoft.com/v1.0/users/email and the select command to try and get the 'old' name. Howev,er I have not yet found out how to get it.
The reason they move to the cloud is that they are merging two ADs. So some users will be DomainA and some DomainB, but in the same tenant. So my first thought was to try and convert the mail to the other format. However, the two different ADs have different naming standards. One has DOMAINA\fila (two first letters from the first name and two first letters from the last name) and the other one has DOMAINB\firlas. Also it feels really ugly to try and solve it that way.
Is it possible to fetch the users loginname formatted as domain\username via Microsoft Graph?
Using the beta edition of Graph, you can obtain the user's domain and username from the onPremisesDomainName and onPremisesSamAccountName properties:
/beta/users?$select=userPrincipalName,onPremisesDomainName,onPremisesSamAccountName
The domain is stored as a FQDN so you'll need to do some translation. For example, domainName.ad.contoso.com might translate to domainName\).
This will give you a workaround so you can match up users with your internal databases. It is however only a temporary solution. Long-term, you really want to migrate to using the userPrincipalName. This is the primary user identifier and guaranteed to be unique within a given tenant.
Azure AD is a little different than the legacy Active Directory. Certain concepts from legacy AD such as Organizational Units (OUs), Group Policy Objects (GPOs), Kerberos Authentication, Lightweight Directory Access Protocol (LDAP), Domain trusts between multiple domains, and several others simply do not exist in the cloud.
I need to set a server that creates self-signed certificate when a user register in. So i thought to create a new AD account every time a new users register to the server. BUT, I need to store the user information into a sql server and i can't find a way to do this.
Any idea?
Based on what you describe and your comment:
My problem is that i think that store "public users" (that can register from the web) information into AD is insicure, so i'm trying to find another way to do that "mapping", – Stefano
What you seem to need is an AD domain with a one-way trust:
Your public users are in domain A.
Domain A trusts your internal private domain B.
Your app does AD authentication against domain domain A, and your internal users can authenticate using their full domain credentials (the request gets passed to domain B, which says yay or nay).
Note that this is coming from a guy who hasn't used Windows in a very long time.
I could be giving you terrible advice (and if I am I'm sure one of our Windows folks will clobber me for it).
If you're going to be storing external users for an application, you should be using AD LDS (formerly ADAM) instead of real AD. Or any other generic LDAP, really, but AD LDS is a lot like AD and might fit your needs better.
I have some clients that I'd like to put into Microsoft CRM (3.0 Dynamics). These people are already in a small Active Directory group for access to a couple of internal applications.
Is there a way to add these people to CRM and pull/push the contact data from Active Directory, so I'm not creating a second repository of information that conflict?
Unfortunately there's no out-of-the-box way to dot his. You'd have to write a custom app in order to query AD and pull in the data. Unless you're looking at over 100 customers you probably won't make up the time it would take you to manually input this data.
I have a project requirement where I need to authenticate against ActiveDirectory in a remote/disconnected WPF application.
There is probably several ways to attempt to do this, but what would be the best approach using ActiveDirectory's MembershipProvider?
I need to:
Authenticate that the user exists.
obtain the AD user's groups and roles.
This needs to happen from a remote location, outside of the network Active Directory resides on.
From within a WinForms or WPF application you can now take advantage of "Client Application Services" (thanks MS for a very generic name, searching for help is now very painful!).
This allows you to connect to a WCF service that can validate the logins. The link above has a walkthrough that shows how easy it is to get it all working, once you have a working app you can modify your config to point to a different MembershipProvider and/or RoleProvider.
It's worth noting that the out-of-the-box solution includes a MembershipProvider named ActiveDirectoryMembershipProvider, but there's no RoleProvider for Active Directory.
If you do require the ability to get Roles (or Groups) and you are working with .NET 4.0 then you can take advantage of the new Active Directory API added that makes everything much easier, namely System.DirectoryServices.AccountManagement. For the most basic of Membership and Role services you'll want to have the following to create your own basic MembershipProvider and RoleProvider:
MembershipProvider.ValidateUser() - should use PrincipalContext.ValidateCredentials()
RoleProvider.GetAllRoles() - use a new GroupPrincipal() as a source to a new PrincipalSearcher()
RoleProvider.IsUserInrole() - use UserPrincipal.FindByIdentity() method to get a user, use GroupPrincipal.FindByIdentity() to get the group, then use the IsMemberOf() method on the user to see if they're a member of the group.
You can implement as little or as much of the API as needed, you should find everything you need in the new AccountManagement namespace to do this.