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.
Related
Is there a way to protect the database from deletion? I mean it's very easy to click on the "x" next to the root node. This would destroy the whole app and cause an enourmous mess to deal with.
How to deal with this fragility?
EDIT:
Let's assume I have two firebase accounts: one for testing and one for the launched app. I regularly log in and out to use the other one. On the test account I delete whole nodes on a regular basis. An activated password protection would avoid a very expensive confusion of the two accounts.
If you give a user edit access to the Firebase Console of your project, the user is assumed to be an administrator of the database. This means they can perform any write operation to the database they want and are not tied to your security rules.
As a developer you probably often use this fact to make changes to your data structure while developing the app. For application administrators, you should probably create a custom administrative dashboard, where they can only perform the actions that your code allows.
There is no way to remove specific permissions, such as limiting the amount of data they can remove. It could be a useful feature request, so I suggest posting it here. But at the moment: if you don't trust users to be careful enough with your data, you should not give them access to the console.
As Travis said: setting up backups may be a good way to counter some of this anxiety.
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.
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.
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
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.