I recently enabled ldap synchronization in my Alfresco Community Edition instance (running 5.1).
I checked the logs and it appears that the sync is working fine. For my test, I setup an instance running OpenLDAP.
2016-10-20 20:22:39,925 INFO [security.sync.ChainingUserRegistrySynchronizer] [localhost-startStop-1] Synchronization,Category=directory,id1=ldap1,id2=6 User Creation and Association: Commencing batch of 0 entries
2016-10-20 20:22:39,925 INFO [security.sync.ChainingUserRegistrySynchronizer] [localhost-startStop-1] Synchronization,Category=directory,id1=ldap1,id2=6 User Creation and Association: Completed batch of 0 entries
2016-10-20 20:22:39,960 INFO [security.sync.ChainingUserRegistrySynchronizer] [localhost-startStop-1] Finished synchronizing users and groups with user registry 'ldap1'
It is showing zero above because an earlier run synced successfully. I was also able to verify this by checking the postgres database
COPY alf_authority (id, version, authority, crc) FROM stdin;
12 0 testuser1 1280826318
13 0 testuser2 2382010757
testuser1 and testuser2 are what I added on LDAP.
However, when I check the users added under admin tools (http://localhost:8080/share/page/console/admin-console/users on my instance) I don't see these users
I've looked at many links and forums and this doesn't seem to be discussed. Is there anything I am missing?
We had the same issue for new test user : they were synchronised, could log in alfresco with but not visible in admin tools...
But we could access the modification page of the users by typing the correct url by hand.
The problem came from the filed LDAP LastName on our AD which was empty.
We added infos to the LastName field and voilà ! We can now see them in the Admin Tools...
May be it is your case ?
Related
Alright, so I have a Microsoft Imagine account from school through which I've gotten both Azure and Microsoft Visual Studio 2017 in order to learn ASP.NET (worked with Django earlier).
So I've gone throught a whole bunch of tutorials from codeschool to virtual academy to docs.microsoft and finally got the first version of my webapp done and ready to be published to Azure.
So I look through the steps on how to publish, here's some info on that:
Subscription: Microsoft Imagine
Resource Group: <name> (northeurope)
App Service Plan:
Resource Group: <name>
Pricing Tier: Free
Location: North Europe
Status: Ready
Subscription Name: Microsoft Imagine
Click on "Explore additional azure services" (as per many tutorial instructions) and add a database, I've fortunately already created the database in Azure so I only have to connect it. Here's some info on the database (though creating it directly here generates the same error):
Resource Group: <name>
Status: Online
Location: North Europe
Subscription Name: Microsoft Imagine
Server Name: <servername>.database.windows.net
Pricing Tier: Free (5 DTUs)
Some info on the server that the server:
Resource Group: <name>
Status: Available
Location: North Europe
Status: Available
So everything looks really good and I'm ready to publish and I hit the Create-button.
Deploying: (step 0 out of 5) ...
Deploying: (step 4 out of 5) ...
ERROR
Details:
Template deployment failed. Deployment operation statuses:
Succeeded: /subscriptions/ ... /servers/mintentadbserver ()
Failed: /subscriptions/ ... /databases/Mintenta_db ()
40619: The edition 'Free' does not support the database data max size '1073741824'.
Succeeded: /subscriptions/ ... /firewallrules/AllowAllAzureIPs ()
Succeeded: /subscriptions/ ... /sites/MinTenta ()
Succeeded: /subscriptions/ ... /config/connectionstrings ()
The few duplicate questions I've found on this have close to no answers and just a few suggestions to upgrade (link1, link2).
So I suppose my question is, like many others:
1) How do you change the size of the database?
2) If that's not possible and you cannot have a database with your free account. Why would not just say that instead of using size-restrictions?
I know this question is a little bit old, but I've just ran across the same error and I also couldn't find an answer. However, I managed to work around this issue.
I was following this tutorial (https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-dotnet-sqldatabase) from Microsoft, and since you mentioned the same steps and the same message error I got, I'm assuming you were doing the same thing or at least something similar.
When publishing directly from Visual Studio 2017 to Azure, VS tries to create the following resources:
App service plan
App service
SQL server
SQL database
From your error message (and mine as well), although the SQL database creation had an error, the other resources were published successfully. So, if you access Azure portal, you'll see those resources there.
Then, if you open the SQL server and click "New database", you'll be able to add a database manually - and more importantly, you'll be able to select the free option with max size of 32MB.
(In this example, the button is disabled because I've already added one database - I believe this is another limitation from the students' subscription).
Note that if you add the database manually, you'll also need to configure your connection strings. But that is quite easy:
Open your new database on Azure portal
Go to Settings > Connection Strings
Copy the connection string from there
Now open your App service and go to Settings > Application Settings
On Connection Strings, add a new one or edit the existing one, pasting the content that you just copied from the DB (don't forget to input your username and password)
You can have a DB using a trial (there are no restrictions to trial account as far as I'm aware of, well, except money). I'm not sure how to workaround this issue, as the template is pre-built by VS.
The more I look at this error, the more I don't get it. There is no "Free" tier of the Azure SQL DB. And the cheapest (basic) supports up to 2GB database, so this doesn't really restrict you.
Try setting appservice plan to shared? if that doesn't help try deleting everything and just let VS create all the resources for you, it should work in that case.
I've two server environments, One for testing and the other for production.
Both are working on Ubuntu server 16 and running Odoo 10 Enterprise edition. The only difference is that on the production server I used Nginx to allow Odoo working on port 80 instead of 8069.
Before we migrate our database to the production server, everything was working smoothly. Now the problem is when the sales person who has permissions of "Sales / User: All Documents" and "Accounting & Finance / Billing" tries to register payments for an invoice he gets this message
However he doesn't get the same message in the test server in which the database is the same as the production server db. I checked the access control list of model "account.journal" in both databases and there was no difference between them. I checked the log file and found this error.
odoo.addons.base.ir.ir_model: Access Denied by ACLs for operation: write, uid: 38, model: account.journal
I understand the problem lies in the access permissions. But my question here is why the Sales person was able to register the payment in the test server but not in production server. can anyone help me to understand why this could happen and how to fix it. Could it be due to Nginx?!
Hi you can check your odoo version release, if you download odoo using git you can check it using git log command in your odoo directory, if your last commit is deferent ( local and productio ) maybe that is the problem.
Actually, you can update manually the access right for account.journal table.
I have been working with Oracle SOA Suit 12c human task component. However, I have created a simple bpel processs that takes one input for human intervention and response required by the user assigned. The project deployed successfully to weblogic domain soa_server1. Now the web service is being tested by oracle em->soa_server->composite application. When the user login to worklist, the task is being populated but when he clicks on task, it shows a login form rathar than the huam task form(the jsf/jspx) page.
Additional Details
Weblogic Server 12c, SOA Quick Start 12c(12.2.2.1.0) installed and weblogic domain configured using database. JDeveloper version 12c.
Below is the screenshot of worklist
Can anyone please look in to this, what's the issue??
Issue was related to user assignment in Human Task dedinition.
Double click on human task in your composite.
Go to assignments(user assignment)
My mistake- I had set the owner as weblogic and trying to access the task in worklist with user 'level1'
SOLUTION THAT WORKED FOR ME
Either leave blank to owner text filed or specify all users whom task is being assigned or users who manually clam task.
I haven't tried but probably of you have hierarchy set for users then it might require only top level person to be specified in owner section.
I had a different issue the url in the humantask configuration was pointing to some random name and not the server host name changing that worked
I am setting up Tridion R 5.3 content Manger server on Win 2003 Server. My Windows server is not having Active directory service enabled. The Impersonation user that I have set in Tridion Configuration Manager is
WORKGROUP\mtsuser
since the 2003 server is not under any Domain. Now whenever I try accessing console on //localhost/ and enter my credentials for mts user. The following error is shown with Mesaage on Console reading as "You dont have permission to access R 5.3 contact Administrator."
Event Type: Warning
Event Source: Kernel
Event Category: Security
Event ID: 200
Date: 2/15/2013
Time: 2:11:23 PM
User: WORKGROUP\mtsuser
Computer: WORKGROUP
Description:
Unable to Initialize TDSE object.
Access is denied for the user WORKGROUP\mtsuser.
Error Code:
0x80040302 (-2147220734)
Call stack:
SystemBLST.GetUserContext
SystemBLST.IBLSecurityST_GetUserContext
TDSE.Initialize
Please help In dire need of a solution....
If your machine is not under domain then where does WORKGROUP\mtsuser come from? Who is managing its credentials? I think you should use local machine name\mtsuser and manage credentials locally. Besides you are not supposed to be able to access CME with MTSUser. This user is system user and is only to be used by the system. Also, as you are on 5.3 version, you should check documentation and make sure you've granted all the necessary rights and permissions to this user.
And you should really consider one of the supported versions of Tridion
MTSUser should not be set as an impersonation user, this is your SYSTEM account
"Access is denied" means literally that the user doesn't have permissions for a given action. Maybe it's not an allowed Tridion user, since you don't have access to Tridion I'd recommend looking at the TRUSTEES table, and finding the MTSUser account there. If it doesn't match, then it certainly will not work. Add a record to the TRUSTEES table with the correct information.
As user978511 states, 5.3 is pretty old (early 2008), and not officially supported anymore, but I doubt you can do anything about that.
The impersonation account should be the same account that runs the application pool in IIS - by default this is Network Service
I have got most of the way but there seems to be a permissions issue somewhere:
Before the restore everything is working fine in my target environment - target has a server login account TCMDBUser which is mapped to my tridion_cm database user TCMDBUser
My source tridion_cm database has user TCMDBUser_DEV.
After restoring the source .bak into my target TCMDBUser_DEV is orphaned.
I edit the TRUSTEES table to correct MTSUser and my admin log accounts for my target environment and run the following to fix up my orphaned database user:
sp_change_users_login #Action='update_one',
#UserNamePattern='TCMDBUser_DEV',
#LoginName='TCMDBUser'
GO
I can log back in to Tridion explorer and see the expected list of publications and can walk through the tree structure but when I come to a folder which should contain items I see nothing with error:
and the corresponding event log error is:
Unable to get list of SDL Tridion Content Manager items.
DESCRIPTION
Error Code:
0x80040000 (-2147221504)
Call stack:
System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.GetOrdinal(String)
System.Data.SqlClient.SqlDataReader.get_Item(String)
Tridion.ContentManager.Data.AdoNet.DatabaseUtilities.ConvertToFieldDictionary(IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.IdentifiableObjectDataMapper.Read(TcmUri,IDataRecord,IDictionary`2)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.GetListItemsPost(IDataReader,TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.Data.AdoNet.ContentManagement.OrganizationalItemDataMapper.Tridion.ContentManager.Data.ContentManagement.IOrganizationalItemDataMapper.GetListItems(TcmUri,OrganizationalItemItemsFilterData)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsData(OrganizationalItemItemsFilter)
Tridion.ContentManager.ContentManagement.OrganizationalItem.GetListItemsStream(OrganizationalItemItemsFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListItemsXml(UserContext,String,ListFilter,ListColumnFilter)
Tridion.ContentManager.BLFacade.ContentManagement.OrganizationalItemFacade.GetListData(UserContext,String,EnumListKind,ListColumnFilter,String)
Folder.GetListItems
You will need to delete/drop the TCMDBUser_DEV form the DB and then create a new one with the same name and password (or reattach it to your cm DB). That should fix your problem.
I normally use the delete method with MS SQL server. I believe this occurs due to the ownership status that the TCMDBUser has on the database Schema.
When complete your TCMDBUser user should have the following permissions on your Tridion_CM database
Like Chris mentioned, I always drop the user from the database and then assign the existing TCMDBUser in SQL Server the rights to the restored database. You can drop the user with the following command (on the restored database):
EXEC sp_dropuser TCMDBUser
Then through the SQL Server - Security - Logins, you request the properties of your TCMDBUser and in the User Mapping add the following database roles: db_datareader, db_datawriter and db_ddladmin.
That's what I've always done in the past and works for me, not sure if its all required, but worth a try I guess
Try creating new user TCMDBUser in the database and run the following command
EXEC sp_change_users_login 'Update_One', 'TCMDBUser', 'TCMDBUser'