I am trying to setup solr and one of the thigs I have trouble with is security.
I have two cores: project-1 and project-2
I also created two users: project-1 and project-2
Now I am trying to setup permissions but it is confusing to me how to do it.
From what I understand from documentation I need to create a permission called project-1, assign it to a group called project-1 and assign that group to user project-1, that I do understand.
But I am having an issue with creating the permission itself.
It seems I have two fields to fill: collection and path.
Should I set collection = project-1 or path = /solr/project-1/* or both, or maybe something else?
Related
We've created an application using SCIM 2 SDK from PingIdentity for provisioning with Azure AD. Custom mapping is set up and working.
However, when the user is CREATED, all of the fields are included in the import, but only a few fields are included in the provisioning step and sent to our application. Provisioning needs to run a second time on that user to UPDATE in order for all the fields to be included. Amongst other things, this means that first and last name are not split and it only sends the displayname (which ends up as firstname on our end).
For some users in normal provisioning, it can take days between the create and update runs so we're missing data for a long time.
Anyone know how can we can test for what's causing this and solve it so all the fields are included in the initial CREATE run for a user?
Here are the attribute mapping settings: https://imgur.com/ypfAAmD
And an example log of when the user is created with only basic fields: https://imgur.com/iOXACJh
vs. when the user is updated with all the other fields: https://imgur.com/UqDNyCv
I'm a product manager at Microsoft that works on the provisioning service and our SCIM client.
The behavior you're seeing occurs when you have attributes that are not part of the SCIM core schema included as "short" names. Attributes not defined in the SCIM core schema (RFC 7643) should have full URN syntax. Something to the effect of urn:ietf:params:scim:schemas:extension:appName:2.0:User:attributeName is commonly used by other implementations. The shaky behavior you're seeing where the AAD provisioning service fails to send these attribute values via a POST but later includes them in a PATCH comes down to different code paths in the AAD provisioning service, and the PATCH code happens to handle this differently than the POST code. This is purely by chance, however, and isn't an intentional design choice. At some future point I'm hoping we'll make this more consistent and disallow incorrectly structured attribute names entirely.
If you adjust your attribute names to align with the guidance in the SCIM spec's schema RFC and provide the attributes with fully defined URNs, you should see consistent behavior that works on both POST and PATCH.
I have configured TeamCity (8.1.4) for LDAP logins and it works as advertised including synchronization of displayname and email. But I have a problem with synchronization of VCS properties.
New users are being created (when they first log in) without their display name or email address being populated. This is remedied when the sync happens, so I know the sync works for those properties.
I need the "Default for all of VCS roots" property filled out properly as well though. This is required so that people can be matched to their check-ins (it's not happening at the moment) so they can be emailed when they break the tests.
The "Default for all of VCS roots" property is simply being populated as username, but I need it to be DOMAIN\username.
My settings:
java.naming.provider.url=ldap://my.domaincontroller.com:389/DC=mydomain,DC=local
java.naming.security.principal=monkey
java.naming.security.credentials=bubbles
teamcity.users.base=OU=group2,OU=Users
teamcity.users.login.filter=(sAMAccountName=$capturedLogin$)
teamcity.users.username=sAMAccountName
teamcity.auth.loginFilter=.*
teamcity.options.users.synchronize=true
teamcity.users.filter=(objectClass=user)
teamcity.options.groups.synchronize=false
teamcity.options.createUsers=false
teamcity.options.deleteUsers=false
teamcity.options.syncTimeout = 3600000
teamcity.groups.property.member=member
teamcity.users.property.displayName=displayName
teamcity.users.property.email=mail
teamcity.users.property.plugin\:vcs\:anyVcs:anyVcsRoot=mydomain\\$sAMAccountName$
You can play around with the settings for LDAP to achieve this but we ran into some issues when we set this up on our projects. We had more than one type of VCS repo and when we started to move to Git, our repository just did not store usernames in DOMAIN//username syntax.
A better way would be to update the user tables in teamcity database to set the default userid for all TFS based roots to DOMAIn/username. This is the syntax
insert into user_property
values(<user_id>,'plugin:vcs:jetbrains.**tfs**:anyVcsRoot','DOMAIN//username')
When I lookup a user in AD, can the user have 2 entries across 2 controllers which are different?
If lookup #1 returns an entry and a reference, do I need to follow the reference in order to gain additional information regarding the user? Or will the reference have the same information and hence can be ignored?
userPrincipalName uniqueness is not enforced by Active Directory. It's the applications which create the user object or modify the userPrincipalName responsible for making sure it's unique across the forest. If Active Directory detects there is more than one user object with the same userPrincipalName assgined, the user will be unable to logon using that userPrincpialName. Check out this Microsoft KB for details.
There are a lot of reasons that you can receive a LDAP reference result. One common reason is that there are some child domains under a parent domain and you are trying to do a subtree search starting from a parent domain.
The domain controller from parent domain cannot provide a complete answer to your query because some of the directory partitions are being taken care by the domain controllers of the child domains. Therefore, it returns you some Subordinate References. It hints the client to follow the reference and get the complete result. For a complete list of reference result, you can check here
If I understand your question correctly, you run a LDAP query based on the userPrincipalName and already got one entry back from the parent domain. You are asking whether you should stop the query or you should follow the reference and continue the query. I would say you should always follow the reference and continue the query. If you find more than one user object with the same userPrincipalName, you probably want to handle the case properly. For example, like what Windows did, stop the user from logging on or give a warning message somewhere.
Let's say I have a Project model and a User model in a CakePHP application. Using ACL I can control if users can access to projects and/or to particular actions in a ProjectsController.
But I would like to go further and control whether a user is allowed to view a specific project, e.g. accessing a project with id = 3 using a URL like http://example.com/projects/3.
Is this possible with ACL as well or I have to develop additional checks on top of it?
Thanks!
To restrict access to specific values of a model, you'll need to use something other than ACL.
It'll be best to define a relationship between the users and projects, whether that's inclusive or exclusive.
You're probably needing a ProjectUser model (HABTM in Project and User) and a simple function in that model, maybe userAllowed($projectId, $userId), that checks that the user has been given access to that project.
I am currently working on a project whereby I have to make both openERP and SugarCRM talk to each other.
For example, if I add a new Account in SugarCRM, this account is also created in OpenERP...and if I create a new Customer in OpenERP, a new customer with same values is created in SugarCRM.
I've searched the net and I found a connector which allows this interfacing.
http://www.sugarforge.org/projects/sugar2openerp
This connector is not an easy thing to work with...I had to build a module inside SugarCRM for me to input connection details (url, username, password, etc ).
Now, I dont know how to proceed with the connector...the files contained in it mentioned "accounts_cstm"... should I create it or no?
Have you looked at the import_sugarcrm module (http://apps.openerp.com/addon/6970)?
I've never used it, but it is an certified OpenERP module, which means that it is officially supported by OpenERP SA, so you should be able to get support and post feature requests if necessary.
all table names ended with "_cstm" are the upgrade safe portion of the data you create in SugarCRM (_cstm for "custom"). For example if you add a new field to accounts, the original structure doesn't change. SugarCRM creates your new field in this table, and relates to the original accounts table thru id_c field.
I didn't test the module you are mentioning here, but if well constructed there wouldn't be need of creating such table.