On our on-premise TFS 2017 update 2 I want to add an extra user to the Agent Pool role as an administrator. For some reason I can not find all users in the domain.
In the image you can see that the user TFSBuild was added previously, but now when when searching or it it can not be found. I know for certain that this user still exists because in other place (e.g. add it to a a project group) I can add it. Also I'm able to add other users so the permissions to add users to the administrator role are OK.
I noted that I can add the user to the 'Project Collection Build Administrator group' but I still cannot add it to the Agent Pools or it doesn't show up in the 'filter users and groups' of the collection
First you could try to add that specific user to another agent pool. This will narrow down if the issue is related to the agent pool.
It maybe an Identity Synchronization issue, you could check this blog which discusses how to do a force sync.
Besides, you could also directly add group instead of a user on the agent pool. The users in the group will also gained the roles. And based on the roles, they will govern what operations they can perform on an agent pool.
So as a workaround, you could add a group which only included this user instead of this user, then double check if the user has properly permission.
What I do is add the user or AD-group to a team project TFS group as member. For example as a reader. Then the synchronization is done by TFS and you will be able to resolve and add the role member in the agent pool after a few minutes.
Related
Is there a way to make admin not able to delete user from Active Directory? I need to disable this feature some how in global properies or else. I want admin only to create users,edit them and disable them, but not delete. The version of Alfresco is Community 5.2. Thanks in advance.
I guess you mean the other way around:
Is there a way to prevent admin from deleting users which have been created by ldap sync?
or do you mean:
Is there a way to revoke permission to delete any user?
Do you understand the difference between a user which has been created by ldap sync and a user manually created in the Alfresco admin UI?
There is no (easy and supported) way I know of to restrict admin permissions or for a member of the group ALFRESCO_ADMINISTRATORS. The ROLE_ADMINISTRATOR has always any permission.
There maybe a way to achieve what you expect in a customization module implementing a new behavior which disallows user deletion in a specific zone or by creating your own permissionGroups/permissions in a customPermissionDefinitions, setting the new introduced permissions on the user zones to specific groups but that kind of customization would be hard to maintain on later updates/upgrades.
EDIT:
What is your use case for allowing (end) users to create new users inside Alfresco although you have an user directory (AD) in place?
If your aim is to support external users, managed by specific internal user groups you may add another directory like samba4 which your internal users may get permissions to create/delete users (that's what we actually do from/thru our CRM system) or if you prefer integrations with OAuth2 providers such as Google, Facebook, Github you may take a look on the Spring Cloud Gateway for the Alfresco platform project
I have created a secondary User store using LDAP. By default, all users of the secondary store have no permission. Is it a way to assign the suscriber role to all users in one operation or I have to do it manually for each user ?
Thanks
Since by default WSO2 uses groupId('Organization) of the user to share the Application in the Devpotal as mentioned here in the documentation: sharing applications
You can go to the Carbon UI and search for the LDAP users among which you want to share an Application. Next to the User click on the 'User Profile' tab. There you can edit the value next to the 'Organization' column. For this, your secondary user store should be 'ReadWriteLDAPUserStore'. Similarly, edit the value for each user in the secondary user store to the same value to share the Application among them.
In fact, in the ldap user store if you configure LDAP groups there are automatically created as a role and you can apply permissions to a role which will be apply to all users of your LDAP group.
But I didn't find a way to share applications between users of a LDAP group ...
Here is a better way to achieve it. In the official documentation it is mentioned that it allows the Applications to be shared if we have common roles, in as you said WSO2 treats AD groups as roles. Lets assume you have two users user1 and user2 in your LDAP store both of which are the part of AD group 'AD_Group'.
So mention the AD group name common to the users among which application needs to be shared : -
Also change the configuration as following in the deployment.toml file : -
[apim.devportal]
enable_application_sharing = true
#application_sharing_type = "default"
application_sharing_claim=http://wso2.org/claims/role
After referring so many forums, I am able to authenticate and sync active directory users to alfresco. The problem is we have more than 25,000 users and rite now we are planning to open alfresco only for selected users. Whenever someone search people they will be finding all the 25,000 users who are not even using alfresco. My It team is not willing to create seperate group for these selected members. Is it possible to sync only users who are logged in.
I am using alfresco 4.2e Binary Installation. Windows 7 64 bit.
The most easiest way would be to distinct users to sync via LDAP query.
You could find this link useful.
This scenario should do it:
enable ldap authentication
configure the authenication chain to include Alfresco and LDAP. This will ensure to try to authenticat against both systems. e.g.
authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap-ad1:ldap-ad
disable sync
# This flag enables use of this LDAP subsystem for user and group
# synchronization. It may be that this subsytem should only be used for
# authentication, in which case this flag should be set to false.
ldap.synchronization.active=false
If you start Alfresco the very first time there is no user in Alfresco. Depending on your strategy how to control the user creatioin you could ether:
create user manual
If you're running on linux the easiest way would be to use the alfresco-shell-tools otherwise you could use the csv-import feature in the user admin. The trick is to use the same username so Alfresco will try to authenticat against both systems before it fails.
create user on first login
Another way is to enable implicit user creation on first login. This isn't my recommendation since you will get trouble later because the user has no email address configured / no user info is synced. (This way is not tested - if this doesn't work you may define a sync query which doesn't return users to enable sync)
synchronization.autoCreatePeopleOnLogin=true
you will get the auto-creation of people who were successfully authenticated but weren't brought in by the sync
you need to add/change this line also on ldap-authentication.properties :
ldap.authentication.active=true
ldap.synchronization.active=false
ldap.synchronization.autoCreatePeopleOnLogin=false
synchronization.syncOnStartup=false
synchronization.syncWhenMissingPeopleLogIn=false
and add on alfresco-global.properties :
create.missing.people=false
I need newly created users to be assigned to a particular role as default.
as default, a new user automatically assigned as "authenticated user" I also need as "content admin (custom created role)"
any idea how to do that?
appreciate helps!!
Why I need that?
I create a content admin role for client, I dont give administrator access. and they need the ability to create new users as content admin. as default I need to give access to "administer permission", but by this way they can create administrator user as well :/ and can messed up with the site. So, if I can assign content-admin role as default to new created users, i wont give administer permissions access to client.
Take a look at the module Auto Assign Role. It allows you to automatically assign roles to new users. You can also set different role presets depending if a user registered himself or an admin created the account. Currently it is only in dev for Drupal 7, but from the issue queue it seems to be in working condition.
From the project page:
The Auto Assign Role serves three primary purposes. The first is to
provide an automatic assignment of roles when a new account is
created. The second is to allow the end user the option of choosing
their own role or roles when they create their account. The third is
to provide paths that will trigger a specific role when an account is
created. The administrator has full control over these functions and
can have them working together or independently of each other. Auto
Assign Role is integrated with the Content Profile module so that you
can have content types serving as registration pages. You can even
replace the default user/register page with a customized version of
your own design.
We want to give users peoplesoft portal access from outside network. But ..that access needs to be read only and very limited.
Has anyone done location based role enabling is peoplesoft.. i.e. disable all roles and enable only particular role based on ip address or web server ?
I have done something similar to that using DNS entries to determine internal/external access. The users wanted to force Self-Service access to all users when they logged into PeopleSoft if they were at home, but give the users full access if they logged in via VPN or at their desk. That way, power users would not have full security unless they were authenticated via VPN or at work.
We accomplished by customizing the USERMAINT component, created a new security table for "self service" security, adding custom Signon PeopleCode, and setting up a 2nd DNS entry that was exposed for external access.
To start, the network admin set up two sets of DNS entries that pointed to the PS web servers. For example, psoft.company.com was the internal DNS and only set for local network access, and selfservice.company.com was the external DNS available for global access.
Next, we customized the USERMAINT component (User Profile). We hid the delivered Roles tab and replaced it with a copy. The new page was pointing to a copy of PSUSERROLE. We did this because we want to use the delivered PSROLEUSER table as the "current" security table. If the Security Admin wants to update a users internal (or day-job) security, we want to store if for long term. (This will make more sense below). So the new custom table, say XXROLEUSER, is now the master table for security.
Then, we added record/page/component for the Security Admin to define "self service" security (XXSSROLES). This record/page just stores Role Names for when users log in externally. This allows the Security Admin to update self service security for seasonal changes, like Open Enrollment. The admin can add a role during Open Enrollment to grant additional access, and then remove it when the period has ended.
Last, we created a custom Signon PeopleCode step that handles the internal/external security switch. The Signon PeopleCode grabs the URL used to log in. The code parses the URL to see with DNS entry was used to access the system. If the DNS entry is "selfservice.company.com", the code will clear our the rows in PSROLEUSER for the user and insert the roles from the XXSSROLES table. If the DNS entry is "psoft.company.com", the code will clear out PSROLEUSER and insert the roles form the XXROLEUSER table.
This code change turns PSROLEUSER into a transaction table. Because the Tools system relies on this table for many different security functions, it is important to create a copy to use as the "master table" for use in the User Profile component.
If this is something you are interested in trying, I'd be happy to post some sample code for the Signon PeopleCode.
I uploaded the Signon PeopleCode function to GitHub (see link below). You can create a custom record to store the PeopleCode and then add it into the Signon PeopleCode page. If you need more information, let me know. I am not able to post the entire tech spec, but I'd be happy to help if you have questions.
http://github.com/iversond/PeopleTools-Dynamic-Login
Recruiting Solutions uses a similar process - when creating the external Candidate Gateway to allow applicants to apply for positions, a 'guest' ID is created for a particular web server that has severely restricted permissions - basically just the external applicant apply objects.
In PS 9 , have a look at PeopleTools > Web Profile > Web Profile Configuration under the security tab. You can definitely secure the system at a web server level.
HTH
Disclaimer: I work for the company.
A bit late to the party, but a useful answer: IntraSee has developed a solution for this exact situation.
The key is that you need to be able to define rules (locations) and then tie those to specific roles. Evaluated at login, the roles are revoked or granted depending on the rules and user location. It can use IP or other attributes to determine roles.
To do this manually is slightly tricky as you need to account for the versioning of the user profile and associated permissions. Signon PeopleCode is the best place to evaluate these rules as you can do it once per session, and you ahve access to the business data to make correlative decisions. E.G. if a person has a huge approval limit, maybe they can't approve remotely, but someone with a small limit can. Same security access, but add or revoked based on location and data.
To your specific case: you would have base roles with read only access to those users, then a set of 'opt-in' roles that gave read/write. When they come in from the correct location, they get the read/write. So, we are only adding the extra access when appropriate.
I would create a separate site ( like the candidate gateway suggestion ), it will need a similar web profile as the one you are currently using, no other changes would be necessary.
Next create a custom menu, then attach all of the components you wish to make read-only.
Register the content references for those custom_menu.components.
Create Roles and Permission Lists adding the custom_menu.components then select "Display Only". Then assign the roles to the users.
Expose that site via the firewall.
That's it.