Invalid private key for Encryption App


When new users logon to our OwnCloud via LDAP, they get "Invalid private key for Encryption App" and when they go to change their password to recreate the private key, the app just sits at "saving...." and does not continue on.

Steps to reproduce

  1. Logon with an LDAP account of a user that has never logged on before
  2. Get the error message
  3. Try to recreate the new private key by entering the old and new password, which happen to be the same because the password has not changed

Expected behaviour

New private key is created and user can continue on using the system

Actual behaviour

The page sits stating "saving..." located after the "Update Private Key Password" button

Server configuration

Operating system: CentOS7

Web server: Apache

Database:

PHP version: 5.6

ownCloud version: (see ownCloud admin page) 10.0.4.4

Updated from an older ownCloud or fresh install: Updated from 9.1.7 a couple weeks ago

Where did you install ownCloud from: Package

Signing status (ownCloud 9.0 and above):

No errors have been found.

{
"basic": {
"license key": "REMOVED SENSITIVE VALUE",
"date": "Thu, 11 Jan 2018 14:15:46 +0000",
"ownCloud version": "10.0.4.4",
"ownCloud version string": "10.0.4",
"ownCloud edition": "Community",
"server OS": "Linux",
"server OS version": "Linux REMOVED SENSITIVE VALUE 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017 x86_64",
"server SAPI": "apache2handler",
"webserver version": "Apache\/2.4.6 (CentOS) OpenSSL\/1.0.2k-fips mod_fcgid\/2.3.9 PHP\/5.6.32",
"hostname": "REMOVED SENSITIVE VALUE",
"user count": 12,
"user directories": 12,
"logged-in user": "Eric Fanning"
},
"config": {
"updatechecker": false,
"instanceid": "oczcbaoff560",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"skeletondirectory": "",
"trusted_domains": [
"REMOVED SENSITIVE VALUE"
],
"datadirectory": "\/var\/www\/Owncloud data",
"overwrite.cli.url": "https:\/\/***REMOVED SENSITIVE VALUE***\/owncloud",
"dbtype": "mysql",
"theme": "briljent",
"version": "10.0.4.4",
"dbname": "owncloud",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"logtimezone": "America\/Indiana\/Indianapolis",
"installed": true,
"mail_smtpmode": "smtp",
"mail_domain": "briljent.com",
"mail_smtphost": "mail.briljent.com",
"mail_smtpport": "25",
"mail_from_address": "files",
"loglevel": 1,
"maintenance": false,
"ldapIgnoreNamingRules": false
},

```

**List of activated apps:**

Enabled:
- activity: 2.3.6
- comments: 0.3.0
- configreport: 0.1.1
- dav: 0.3.2
- encryption: 1.3.1
- federatedfilesharing: 0.3.1
- files: 1.5.1
- files_external: 0.7.1
- files_sharing: 0.10.1
- files_trashbin: 0.9.1
- files_versions: 1.3.0
- files_videoplayer: 0.9.8
- gallery: 16.0.2
- market: 0.2.3
- notifications: 0.3.2
- provisioning_api: 0.5.0
- systemtags: 0.3.0
- templateeditor: 0.1
- updatenotification: 0.2.1
- user_ldap: 0.10.0
Disabled:
- external
- federation
- firstrunwizard
- shorten
- theme-example
- user_external

**Are you using external storage, if yes which one:** No

**Are you using encryption:** Yes

**Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory

#### LDAP configuration (delete this part if not used)

+-------------------------------+-----------------------------------------------------+
| Configuration | s01 |
+-------------------------------+-----------------------------------------------------+
| hasMemberOfFilterSupport | 1 |
| hasPagedResultSupport | |
| homeFolderNamingRule | |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | CN=owncloud,OU=ServiceAccounts,DC=briljent,DC=local |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | dc=briljent,dc=local |
| ldapBaseGroups | dc=briljent,dc=local |
| ldapBaseUsers | dc=briljent,dc=local |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | mail |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | objectguid |
| ldapExpertUsernameAttr | |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (|(cn=BriljentEmployees)) |
| ldapGroupFilterGroups | BriljentEmployees |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | |
| ldapGroupMemberAssocAttr | uniqueMember |
| ldapHost | briljentwin13.briljent.local |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | sAMAccountName=%uid |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 0 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 389 |
| ldapQuotaAttribute | |
| ldapQuotaDefault | |
| ldapTLS | 0 |
| ldapUserDisplayName | cn |
| ldapUserDisplayName2 | |
| ldapUserFilter | (&(|(objectclass=user))) |
| ldapUserFilterGroups | |
| ldapUserFilterMode | 0 |
| ldapUserFilterObjectclass | user |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| useMemberOfToDetectMembership | 1 |
+-------------------------------+-----------------------------------------------------+

### Client configuration
Browser: Chrome and IE

Operating system: Windows 10

ownCloud log (data/owncloud.log)

{"reqId":"WldtKahTaVhoJiqbJkSr4AAAAAg","level":2,"time":"2018-01-11T08:56:57-05:00","remoteAddr":"10.0.6.35","user":"062E32A3-DD22-45B6-8112-A255B8341B7E","app":"core","method":"POST","url":"\/index.php\/apps\/encryption\/ajax\/updatePrivateKeyPassword","message":"Login failed: '062E32A3-DD22-45B6-8112-A255B8341B7E' (Remote IP: '10.0.6.35')"}
{"reqId":"YnveE2rEg6eX4qyLD7Nq","level":3,"time":"2018-01-11T09:00:02-05:00","remoteAddr":"","user":"--","app":"files","method":"--","url":"--","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"YnveE2rEg6eX4qyLD7Nq","level":1,"time":"2018-01-11T09:00:03-05:00","remoteAddr":"","user":"--","app":"cron","method":"--","url":"--","message":"Invalidating tokens older than 2018-01-10T14:00:03+00:00"}
{"reqId":"WldwVC82i4wGxYmxgxHkOAAAAAc","level":3,"time":"2018-01-11T09:10:28-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"Wldw5XjxpizSKYn7JNxD@AAAAAs","level":3,"time":"2018-01-11T09:12:54-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"Wldw56hTaVhoJiqbJkSr9QAAAAg","level":3,"time":"2018-01-11T09:12:56-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"WldxDG@r6i-xOIj6aFWvuQAAAAA","level":3,"time":"2018-01-11T09:13:33-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"WldxKqGXqWxOxg2JrkDL7wAAAAM","level":3,"time":"2018-01-11T09:14:03-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"WldxP4x8Ub5WGdV7fUCqmQAAAAw","level":3,"time":"2018-01-11T09:14:24-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"WldxY6GXqWxOxg2JrkDL8wAAAAM","level":3,"time":"2018-01-11T09:15:00-05:00","remoteAddr":"10.0.6.35","user":"37F5785B-8F3D-4617-A50D-FA251E6FB6B5","app":"files","method":"PROPFIND","url":"\/remote.php\/webdav","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"mBM4AdhzrEQQQOUjTGLN","level":3,"time":"2018-01-11T09:15:01-05:00","remoteAddr":"","user":"--","app":"files","method":"--","url":"--","message":" Backends provided no user object for 2D965936-9331-44B1-85E5-1D4BA294663D"}
{"reqId":"mBM4AdhzrEQQQOUjTGLN","level":1,"time":"2018-01-11T09:15:02-05:00","remoteAddr":"","user":"--","app":"cron","method":"--","url":"--","message":"Invalidating tokens older than 2018-01-10T14:15:02+00:00"}

Hi,

I suppose this is a test installation, correct?

did you configure the Expert tab?
try setting samaccountname for the “Internal User name Attribute”

and clearing the tables with the buttons below. if this is a test installation.

Well, yes and no. It is a pilot installation, but there is production items on the server. What will clearing the tables do?

Oh, this is interesting, went to look at the Expert tab and now I'm having an Integrity issue. See below. Could this be part of my issue?

Technical information

=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results

  • shorten
    • EXCEPTION
      • OC\IntegrityCheck\Exceptions\InvalidSignatureException
      • Signature data not found.

Raw output

Array
(
[shorten] => Array
(
[EXCEPTION] => Array
(
[class] => OC\IntegrityCheck\Exceptions\InvalidSignatureException
[message] => Signature data not found.
)

    )

)

can you check if the signature.json file has the correct permissions, i.e. the owner is www-data?

the file is in owncloud/core

after that you should rescan the files

The owner is apache (running CentOS 7) and permission are 644. I re-scanned and it's now cleared up but still getting the Invalid Security issue.

-rw-r--r-- 1 root apache 1519250 Dec 5 11:16 signature.json

It cleared up but you still get the error message?

Is it the same as before?

Btw, the clearing of the tables will just delete the ldapuser - owncloud user tables.

I have seen that you have numeric values for your users, that can be solved if you configure the internalusername to samaccountname in the expert tab. this is recommended by owncloud

I'm sorry, it cleared up the Integrity error message and asking me to rescan, but getting the same message as before in the original post.

Ok, I will give the internalusername a try and then clear the tables and will let you know.

Ok, after clearing the tables, the users are listed three times....

37F5785B-8F3D-4617-A50D-FA251E6FB6B5 Eric Fanning change full name
efanning Eric Fanning change full name
efanning_4578 Eric Fanning change full name

That's strange. could you remove the LDAP server from your owncloud - delete it, and configure it new? Or is it not possible

or could you just click again on the clear the tables?

Probably not during the day, but maybe tonight. What will this do today to the user's files?

I tried clearing again and that didn't help.

I have inherited this server as I am new to the company and not sure on it's build, thinking about rebuilding and running side-by-side then migrate if new one is more stable.

UPDATE: clearing the LDAP tables just created a new user entry for each user, now I have four entries for each user.

The files should be untouched by this command. If you connect an LDAP Server to ownCloud, then ownCloud creates users for every user in LDAP with a mapping table. If you change something like the internal username then the changes only go into effect after you cleared the mapping table.

I have one last idea, can you run the sync command?

https://doc.owncloud.com/server/10.0/admin_manual/configuration/server/occ_command.html?highlight=occ#user-commands

it should go something like

sudo -u www-data php occ user:sync -l

then you will be shown your sources of users to sync from. and you have to choose the proxy one, and put in in "" instead of the "-l" and then choose the disable option.

Ok, I ran that and it did disable, now when I go look at my users, I see all my users from AD instead of just those that have logged on. I am still seeing three entries for those that were there before disabling. And I am still getting the same error message from my original post when I attempt to login.

Edit: It's also showing my computers and servers and adding them as users

And this keeps coming back...

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- shorten
	- EXCEPTION
		- OC\IntegrityCheck\Exceptions\InvalidSignatureException
		- Signature data not found.

Raw output
==========
Array
(
    [shorten] => Array
        (
            [EXCEPTION] => Array
                (
                    [class] => OC\IntegrityCheck\Exceptions\InvalidSignatureException
                    [message] => Signature data not found.
                )

        )

)

how did you configute the users tab in the LDAP Server configuration of owncloud?

I have the "Only these object classes" set to users and have the groups selected that only have groups that have users in them.

Okay, can you open a Issue on GitHub, I can't help you, I am sorry but I am out of options.

Well, thank you for the help that you did provide. I have opened the issue on GitHub.

Not finding "signature.json" could also be caused by a missing configuration in SELinux. Are you running SELinux in enforcing mode by any chance?

@dmitry I ended up finding out that using a user based encryption was not best practice per ownCloud so I ended up rebuilding it with a master key encryption and is working much better. They said that there could potentially more issues than what I was originally seeing if I left it at the original configuration. Thank you for your assistance.

1 Like