a web application I work with requires a form which allows an Administrator to add users into the web applications user table. The web application is intranet based and is run in a number of countries world wide.
They need the ability to search Active Directory to find users to add from across multiple domains. Searching domains that are geographically located further away takes much longer than searching closer domains...
Is there faster ways to search Active Directory, e.g. certain search parameters or eliminating fields to search?
and how would you populate say a session dataset and have a grid or other control refresh to retrieve the data as it is retrieved from each domain...i'm not sure how you could do this as it sounds multi-threaded which i haven't done in an asp.net webapp...
thanks heaps!
In Active Directory the Global Catalog contains a subset of account attributes from all domains in the forest. Since it looks like you just want to find the names that information should be in the GC. If you are doing an LDAP search bind to port 3268 instead of 389 to access the GC on the domain controller. You may need to work with our AD administrator to make sure you bind to a Domain Controller that is also a GC.
http://technet.microsoft.com/en-us/library/cc978012.aspx
http://technet.microsoft.com/en-us/library/cc737410.aspx
This page had information roughly what I was after...Talking about optimising searches etc
http://www.informit.com/articles/article.aspx?p=30117&seqNum=5
Related
My situation is I've created a small website that does a few simple sql queries and updating. One or two of the commands should only be accessed by certain people. The website is on one of our servers so anyone who accesses will already be logged in to AD.
I’ve only done web design when needed and isn’t part of my normal duties and only used it when needed so I’m in need of some guidance.
I know I could create a whole logging in and cookies system or something but it sounds like as only people who are already logged in wouldn’t need that and I would be making the task overly complicated.
Essentially I need the easiest way to allow a situation where only certain AD users can click on a button, is the only way possible making a log in page?
I would really appreciate some pointers in the right direction it doesn’t have to be copy and paste code answers.
If all your users are already authenticated against AD then it would probably be simpler to get their credentials and check their user ID against a lookup list of allowed users which you could hold in a database table.
You could then show or hide, or disable and enable, the relevant controls depending on whether they were found in the lookup.
It would make a pretty seamless experience for the user at the expense of having to maintain the lookup.
Alternatively, you could restrict access based on checking if the user was a member of a particular AD group, which eliminates the lookup table but then requires suitable domain administrator privileges in order to add and remove people from the group.
I have an order system developed on asp.net 4 web forms. I need to store order details (order object) for a user on the cache in order to manage it till I save it in the DB.
I want to install my site at least on two server with option to scale for more in the future .
As you know , the two servers are located behind load balancer , so I need the cached order object to be shared on the both servers.
I hear about App fabric.
Any recommendation to good frameworks to do that , Hope will be simple and easy to maintain one .
Thanks in advance ...
I need to store order details (order object) for a user on the cache
in order to manage it till I save it in the DB.
If your data is not persisted, SQL Server-based Session state will work across machines on a per-user basis and can be configured with a minimum of fuss.
However, I would suggest regularly saving the order to your application database (not just the Session database) so that the user doesn't lose it. This is fairly standard practice on e-commerce sites. Unless the order process is very short, inevitably the user will want to pause and return, or accidentally close the browser, spill coffee into their computer, etc.
Either way, the database makes a good intermediate and/or permanent location for this data.
I got a requirement from client that he wants to know distinct users information from sites and it sub sites those have access to site. There are separate groups for each subsite (contribute, approval and full access). From these all groups find distinct user information.
How can we do that using Object model? Please help me out.
Thanks in advance.
SharePoint 2010 - I use this PowerShell script quite often when someone asks who has permissions to a site. This wont include users given permissions directly, or site collection admins, but it's still helpful.
You must be on the SP2010 server to run this.
#Get a list of groups in a site, then a list of people in each group
Add-PSSnapIn Microsoft.SharePoint.PowerShell
$spWeb = "http://sharepoint/site/"
foreach($group in ((Get-SPWeb $spWeb).Groups)){
foreach($user in $Group.Users)
{$group.Name + " - " + $user.Name
}
}
This is one of those very general requirements that gets very difficult very quickly. It sounds like they are trying to create some sort of security audit.
If you assume each site only has SharePoint groups filled with SharePoint users and everything is inheriting permissions, then it is a little easier. You could recursively iterate over each SPWeb (and the sub-SPWeb's in each SPWeb) to find all the SPGroups. Then, using a Dictionary, you would keep track of the users you find and their permission level. Their permission level is determined by their membership in the group and you'd probably use web.RoleAssignments.GetAssignmentByPrincipal(group) (GetAssignmentByPrincipal) to get the list of assignments (Ex: Read, Contribute, etc).
However, the scenario is probably NOT what your client has. Things to think about (some easier to overcome than others):
What happens when a user exists in multiple groups in the same site?
Users with individual permissions to a site?
Broken permission inheritance at a SPWeb level? What about list permissions? Item permissions? What happens when you see Limited Access?
Are AD groups used anywhere? Do you have to list all the users in each AD group? What about special groups like "ALL AUTHENTICATED USERS"?
Realistically, it is very difficult to write an accurate security audit. The best solution for this is probably to find someone who is familiar with how security should be set up going through each site to fix them.
I have a requirement for a set of asp.net MVC websites as follows:
Multiple sites, using the same codebase, but each site will have a separate database (this is a requirement), and users will login and enter data.
A single site for super users where they log in and work on data aggregated from each of the individual sites.
The number of sites in point one is liable to expand as we roll it out to more clients.
My question is about the architecture of the above - how to manage the data aggregation, given that it needs to be real time. Do we maintain this at the database level (e.g. a view that is essentially a union across the individual site databases), or at the application level.
A few infrastructure points:
We have complete control over the database server and naming of databases.
All these websites are deployed onto a server that we manage.
I'd appreciate any input/ideas from folks that may have done this before.
Does the data aggregation have to be completely real-time, or can you get away with almost real-time? If "almost real-time" is acceptable then you can write a service application that harvests the data from the sites databases into your single central database. As long as the process runs continuously and you don't have too many sites to gather data from the delay should be more or less invisible for the user.
Having a view that accumulates the data from all the databases doesn't sound like a good solution. Not only will it probably be very slow, but you will also have to update the view whenever you add a new site.
What is the intention of the super user site, btw? Is it only for reporting or should super users edit the data across all sites as well? That may affect which solution you choose.
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.