I'm updating code that interacts with the AD in our application. The current code uses the ActiveDs interface. I'm changing the code to use the System.DirectoryServices.AccountManagement namespace. Our application allows a user to store a password hint. This is stored in the AD under a user defined parameter. I know I can do this with the DirectoryEntry.Invoke("put") method.
Is there anyway to do this with UserPrincipal, or do I need to call the GetUnderlyingObject method and then the DirectoryEntry.Invoke("put") call?
Any suggestions/comments would be appreciated.
The UserPrincipal class is extensible, so you can "surface" more of the properties of the underlying DirectoryEntry object right on your user principal.
Using that extensibility technique, which is explained in the MSDN article Managing Directory Security Principals in the .NET Framework 3.5, you should be able to also make available a custom attribute (which I assume is how you store that password hint in your DirectoryEntry) on an extended UserPrincipal class.
Related
When I try querying extensionAttribute with Graph API (Hybrid Exchange), I cannot get any value.
E.g., if I try: https://graph.microsoft.com/v1.0/users/<userid or upn>?$select=extensionAttribute2, I cannot see the value even I know it’s there.
Do you know how to get it properly (or a workaround)?
Thank you
Are these values synced to Azure Active Directory? All properties for the AAD User can be found in the Microsoft Graph API docs here : https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
It sounds like these are being synced from an AAD Connect environment, so it's most likely you are trying to get the onPremisesExtensionAttributes.
Per the description:
Contains extensionAttributes 1-15 for the user. Note that the individual extension attributes are neither selectable nor filterable. For an onPremisesSyncEnabled user, this set of properties is mastered on-premises and is read-only. For a cloud-only user (where onPremisesSyncEnabled is false), these properties may be set during creation or update.
I suggest taking a look more thoroughly through the documentation in regards to this. In addition to that, as you mentioned Exchange, note that the custom attributes from exchange are the same as the extension attributes. For more info on this see : https://github.com/microsoftgraph/microsoft-graph-docs/issues/5950
This is a separate sort of "Extension Attribute" but I figured I would include this in the answer as well. There is a different extensibility section for the Microsoft Graph, and the docs on this can be found here : https://learn.microsoft.com/en-us/graph/extensibility-overview
If you see information on these extensions, know that this is separate from the on-prem extensions.
This is more of a best practices question. Our org currently has "public read" permissions on our org wide defaults for custom objects. We cannot make this private because of the way its working now for internal employees or rather we are trying to avoid this.
I am also creating a customer portal with custom visual force pages...where I display data using SOQL queries.
Is it a good idea to add a clause on the SOQL query to return only those records where the account id matches the logged in user's acount id?
I did it and it works fine...But are there any pitfalls to this method that I am overlooking?
Thanks,
Calvin
Per the Visualforce Documentation
Because standard controllers execute in user mode, in which the
permissions, field-level security, and sharing rules of the current
user are enforced, extending a standard controller allows you to build
a Visualforce page that respects user permissions. Although the
extension class executes in system mode, the standard controller
executes in user mode. As with custom controllers, you can specify
whether a user can execute methods in a controller extension based on
the user's profile.
I believe the idea being, as long as your classes are public with sharing then permissions should be enforced and records should not be returned that the user cannot see (same with fields on a record).
per the Apex Documentation
Apex generally runs in system context; that is, the current user's
permissions, field-level security, and sharing rules aren’t taken into
account during code execution.
Use the with sharing keywords when declaring a class to enforce the sharing rules that apply to the current user. For example:
public with sharing class sharingClass {
// Code here
}
Use the without sharing keywords when declaring a class to ensure that the sharing rules for the current user are not enforced. For example:
public without sharing class noSharing {
// Code here
}
Otherwise you would have to spend hours ensuring that the right permissions applied at exactly the right time for the right user. It would almost completely defeat the purpose of a visualforce page!
I'm implementing the ACL component for my CakePHP app (1.3.14). I have everything setup correctly, but there are a few areas where I'm still fuzzy.
Mainly, do I need to explicitly set rights (ACOs) for a special base user group (AROs)?
For simplicity, let's say I have Administrators and then everyone else (general users). So do I need to create a group for these general users and map all their allow rights? Seems like management of these rights would be never ending as the app grew.
Also, what about assigning users to multiple groups?
Ideally if a person had a user account the Auth component would grant access to the system as a whole. Then ACL would simply deny them from the sections that were protected by an existing group.
It seems like the coupling of ACL and Auth is too high. But it may be my new (limited) understanding. Any clarification would be greatly appreciated.
UPDATE
I've started a bounty. In summary, I want to implement CakePHP ACL (preferably, but a matching third-party component is acceptable) that meets/addresses the following:
Assign users to multiple groups
Easily maintain a "public" user group - don't have to constantly add the controllers/actions a general user can access
Code example of managing access to a controller/access
Code example of properly testing a user belongs to a group.
I think the best you can hope for using Cake's native ACL implementation is something like the following:
cake acl create aro root public
cake acl create aro root registered
cake acl create aro registered administrators
(create acos using AclExtras)
cake acl grant registered controllers
cake acl grant public controllers
cake acl deny public controllers/MySecureController
cake acl deny public controllers/Widgets update
cake acl deny public controllers/Widgets delete
(the above is all done through the cake shell, but is easily translated to the PHP variant)
Basically, you can either use a "default-deny" paradigm (as demonstrated in Cake's own ACL tutorial), or a "default-allow" paradigm as above. Whichever method you choose will depend on how you expect the application to grow: will most of your controllers be public with only a select few restricted to Administrators, or will most of your application be restricted with Public given specific access where needed? Either way, you still need to either grant or deny access.
Notice the two AROs created under root: public and registered. With this model, treat registered as if it were root when creating your ARO tree -- put all of your "real user" groups underneath it. That way, you can use ACL as normal on the objects under registered, and the public users will exist outside of that.
All that said, there's nothing stopping you from using Cake's authentication mechanism and rolling your own access control method. Here's an example: Simple Authentication and Authorization Application. (NOTE: This is written for CakePHP 2.0, but the concepts apply to 1.3 as well).
EDIT -
After re-reading the question and the other responses, I realized you're aiming more for a role-based access control model rather than the traditional one-aro-per-user model of the builtin ACL component. Here are a couple of examples of extending the built-in auth component for RBAC:
Role-based ACL in CakePHP
CakePHP Auth component: Users, Groups, Permissions
Also, this two-part article describes an approach to database-backed role-based authorization that can be applied to your Cake application.
You can have both ACOs tree and AROs tree. In the AROs tree you will have adminsGroup<-usersGroup. You will need to setup rights for these groups. In the ACOs tree you will have baseACO<-subACO<-treeOfACOsForUsers. You will not need to maintain any new ACOs if: 1) userGroups are allowed to use subACO, 2) any new ACO is a child of subACO. The idea is to organize a tree of ACOs, so that if you allow access to a parent all children are accessable automatically. You can have a branch with denied access also. So you will need to maintain (assigning permissions) only several branches close to the root.
You may be interested to look at my PoundCake Control Panel - a plugin implementing ACL with user friendly web interface (CakePHP v1.3 is supported).
UPDATE:
Here is what you need.
How do I Programically determine (using C#) the Domain Controller used for authenticating users using Domain Name?
If you're trying to find out what DC authenticated the current user running your app, you can also look at the LogonServer environment variable - http://msdn.microsoft.com/en-us/library/77zkk0b6.aspx.
Try to use DomainController class from the System.DirectoryServices.ActiveDirectory namespace
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.