We have the ability of "AutoLogin" in our systems.
So if I create a new user in AD as "John" - then John has the ability to access the intranet web site ( we query AD to see if the current user is in AD).
But
We also have a users table (SQL Server) which needs to have the FirstName and LastName of the new user.
We want to update that Users table each time a new user in AD is created - some C# code should be run to enter the relevant data into SQL Server (and some other things).
HOw can I catch the event of "new user in AD created" ?
Check out Ryan Dunn's excellent blog post:
Implementing Change Notifications in .NET
that deals with this exact topic. He offers three options:
Polling for Changes using uSNChanged
Polling for Changes Using the DirSync Control
Change Notifications in Active Directory
and shows pros and cons for each of the options, and some C# code for the third option (Change Notifications).
You can use System.DirectoryServices.Protocols.DirectoryNotificationControl from C# for this purpose so you don't have to poll AD for changes.
WMI is perhaps a second solution you can dig in.It exists AD WMI Providers. Using WMI to Monitor AD gives you some clues about that. This article don't do more than what you get so far, but I think that with WMI events you can create the notifications you need. You can find Microsoft informations about this begining in Monitoring Active Directory Health, especialy Active Directory WMI Providers.
It is unlikely that you can capture that kind of event without wrapping the actual function of adding the new user into some kind of c# routine. If you go down this route, you can add the used to AD and mysql at the same time.
Another option would be to poll the AD users and check this against the existing mysql users and add new when found.
Related
I have a windows service, and want to define two roles (administrator and reader) for all the users whoever tries to access my service. So that whoever is assigned with administrator role can have full control over my system, whereas reader can only do readonly operations.
So, looks like I have two options.
Approach using Database
I can simply use database to maintain and their corresponding roles. so, whenever I get a request based on user context, I can validate by querying the db and validate it.
It sounds simple option, but how to make it safe?
For ex, if some looks at my code in reflector, they can find out which table and manipulate the contents so that they can exploit this solution :(
Approach using Directory Services (AD LDS - LDAP)
Looks like Microsoft defined Active Directory lightweight Directory Service particularly for this purposes. I can probably define my own roles and probably add windows security principals to them so that only the AD LDS administrators can manipulate - looks like better approach.
But, I am not sure how to do this programmatically in c# - can any one give me pointers so that I can have a quick start?
Finally, which option is better/recommended and why?
Update:
Looks like these two User Group and Role Management in .NET with Active Directory , What does "active directory integration" mean in your .NET app? gives me some detail in what I am looking for, and it looks like its probably take some time before I consolidate these to define approach for my app :)
Best Regards!
This will get you the SID of the groups
You just need to determine the SID of the group you determine to be admin
System.Security.Principal.WindowsIdentity identity = System.Security.Principal.WindowsIdentity.GetCurrent();
Debug.WriteLine(identity.Name);
foreach (System.Security.Principal.IdentityReference ir in identity.Groups) Debug.WriteLine(ir.Value);
working on an application that wants to now integrate active directory. should be able to import users from active directory, as well as reflect changes for example if a user is created/deleted/update etc in active directory the user should be created/deleted/updated in the database table the application reads from. I kno that LDap can be used to query the Active Directory to import users, but not sure how to cater for the other areas.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms677625%28v=vs.85%29.aspx
The previously supplied link is a good one. Of those ideas, my general suggestion is to use DirSync. It allows you to poll AD with a token and get all changes since the previous poll. All you have to do is remember the token (it comes back with the response to the query).
I'm developing an application that manages information about users and save the data in a SQL Server. I would like to 'somehow' connect this application with our Active Directory, so all the changes this app will make will be reflected in the Active Directory too (if we add a new user in the app, it will be added also in the Active Directory)
Is it possible? if so, which are my options?
Thanks in advance
Don't do it. Let AD be the authoritative copy of your user base, and let the users always be created in AD first and then propagate to SQL. By letting users be added through a different path (SQL first) you open a huge can of worms with regard to security. If a user is defined in SQL but not in AD, what exactly is taht user? How can he log in? To what groups does he belong? IS he allowed access or not to this resource or that resource? How about cases when an user is added in AD and in SQL with different characteristics and then you need to reconcile.
Modify your application do always create the user in AD, in conformance with the AD policies and security requirements (password complexity being the most trivial example). Then let AD synchronize with SQL.
The way I chose to solve this problem was to add an event that was triggered when I saved my user object. The listener on this event would then send an update to Active Directory. In my case I was doing a one way sync to Active Directory and it was also a best effort attempt, meaning if it failed I was fine with it. If you need to do some more reliability around it you will want to wrap your SQL updates inside of a transaction and only commit after active directory is updated.
If you need a two way sync with Active Directory you will need to look at doing some sort of a background synchronization with Active Directory where you iterate over your users and check for updates in AD.
If you are doing a one-way sync to AD, I agree with Aaron that you should simply have a Trigger in SQL server. Note that this solution may suffer from some problems, like the user accounts already created, user name or password doesn't meet the AD complexity rule. You need to then find some ways to log the error. You may also need a tool to do initial provisioning of your database accounts.
If you want to do two-way sync, I suggest you to read up DirSync. You probably need to write a NT service to do it. I hope you don't store password in your database. I highly suggest you to use Windows authentication. If you do need to sync up the password, you may need to write your own passwordsync and install it in all the domain controllers in your machine.
If you are developing a solution for enterprise, you should look up the existing meta-directory solution products from Microsoft, MIIS, ILM, FIM.
They are all the same thing except with the names different. Many enterprise has adopted this as their meta directory solution. You just need to write up an extension to leverage on its provided infrastructures to do the identity synchronization.
I'm trying to write a central reporting tool that will allow time tracking based on Windows users logging into a domain. Initially I was going to create a small executable that would run on 'all users' start-up on each computer, track the logged in username and update a central database.
The main problems with this would be having to manage the versions on a machine by machine basis and deal with rare but possible instances of the tool failing on specific machines and not being immediately obvious.
Instead I would prefer to create a centralised version but I'm finding the MSDN and Windows SBS 2003 docs very hard to dig through for the answer.
Basically I would like to hook into the 'login' and 'logout' functions on the server and track all information from there. Are there natural extension points here?
Obviously an alternative may be to parse the event logs for the information (but to this point I can't find any windows logs that say 'who' is logging in or out).
Any guidance on the direction or documentation to look at would be really appreciated.
Are there natural extension points here?
No. Or rather, you don't plug into login/logout unless you want to replace the login module (e.g. for a different authentication mechanism): not something trivial to do—too easy to open up security holes (and I expect not a good idea, if not impossible, in .NET).
But as Windows (all NT derived versions) includes the ability to log all logins and logouts, the information you need can be recorded in the Security event log. There are then a number of options for getting at the information.
First: enable audit of login/logout.
This is best done with group policy. For the local machine enable the options in SecPol.msc (local security policy MMC snapin): Local Policies | Audit Policy
Second: read the event log
In the Security Event Log look for logon events (id 4624), there is some documentation of these events here.
Automation of this (e.g. via a scheduled read of the event log) or forwarding events should be easy enough.
Not all logins will go to the dc. For example a laptop may use cached credentials to allow access when not on the domain.
You may also see multiple logins for the same user if they are accessing network resources. I think the most reliable approach would be to have the code running on each machine getting called from one of the login hooks.
You should look into the namespace called Microsoft.Win32.SystemEvents. There are many handlers there, but i believe what you want is the SessionSwitch event, which will tell you if the current user is logging on/off of the box or locks the screen. This is possible because windows switches to a different desktop when the screen is locked/unlocked, so you will be able to catch these.
Then, to get the user information, you could use the UserPrincipal from System.DirectoryServices.AccountManagement namespace using the machine's principal context.
The basic setup is classic - you're creating a Windows Forms application that connects to a DB and does all kinds of enterprise-y stuff. Naturally, such an application will have many users with different access rights in the DB, and each with their own login name and password.
So how do you implement this? One way is to create a DB login for every application user, but that's a pretty serious thing to do, which even requires admin rights on the DB server, etc. If the DB server hosts several applications, the admins are quite likely not to be happy with this.
In the web world typically one creates his own "Users" table which contains all the necessary info, and uses one fixed DB login for all interaction. That is all nice for a web app, but a windows forms can't hide this master login information, negating security altogether. (It can try to hide, but all such attempts are easily broken with a bit of effort).
So... is there some middle way? Perhaps logging in with a fixed login, and then elevating priviledges from a special stored procedure which checks the username and password?
Added: OK, so integrated authentication and windows groups seem to be a fair choice in most situations, so I accepted the relevant answer. Still, if anyone can come up with a non-integrated authentication solution, they'll get an upvote from me.
For WinForms use Windows groups. No passwords are needed because the credentials are inferred from the Windows login using your application.
This is best practice
Basically:
The user belongs to a group (assumes single domain)
Group is a login in the SQL Instance
SQL login maps to a database user
DB User belongs to a DB role
Role has object permissions
It's worth reading up first before having someone try to capture all the information here
Edit:
If you have a workgroup, you can still do it by setting up sqlbox\bob, sqlbox\hans etc in a sqlbox local group.
When someone tries to connect (say bob on his PC) windows will ask them for their details. As long as bob knows his SQLbox account detailsm he can connect.
But then, I've not tried this in a workgroup setting...
In addition to using Windows Domain/AD Groups (put the AD groups in appropriate roles you create in SQL Server, so all account maintenance moves to AD), be sure to use the Application Name in your connection string - this allows you to see which applications are performing operations in the profiler etc.
Because when everyone is logging on as themselves from different applications - windows and web, it helps to know that it's actions taking place through an application and not just any user's ad hoc query through ODBC and Excel, say (if you allow users access to certain views for data export or report writing).
Can't you use Active Directory Groups to make the management of the db connections easier?
From MSDN...
The name can be a Windows user name or a Windows group name, of the form DOMAIN\Name.
That way you may have a few groups, read-only, editor, manager, admin etc. It's how I have achieved similar things in that past with Click-Once apps.
It really is the best choice for what you are doing.
I am assuming this is an existing app? If it was new I would otherwise say to go client server with web-services or similar.
PK :-)
With regards to wanting to hide your authentication and use a single application login with WinForms, if the login has very little privilege - select only on views and execute only on stored procedures, anyone who manages to reverse engineer your encryption of the login information in your application will only be able to perform the same functions they could perform in your application. If you absolutely have to raise the level on the security, you could authenticate each stored proc against your users table (poassing user and hash to each SP). Also, rotate the central application login on a regular basis.
All this is a lot more difficult than using integrated authentication and implementing AD platform in your environment. So you're effectively writing your own directory and authentication instead of using one off the shelf.
In addition to gbn's update about workgroup versus domain, you can run the application with RUNAS /NETONLY /USER:SERVER\USER with user credentials on the domain or server which your machine is not a member of. At the point that the application makes the connection to the database, the remote credentials will be authenticated and used. I have an application which actually checks to see how it was run and if it not run with a particular switch, it prompts for username and password and then re-runs itself using the Windows API using a function equivalent to RUNAS /NETONLY /USER:DOMAIN\USER. This is because our workstations are not currently on the domain (or on a domain with a trust relationship) of the SQL Server. In this case, you could still manage the security in local groups on the SQL Server or groups on the domain of the SQL Server. You would basically just lose out on the automated authentication token.