Bug 67058 - 2 errors when joining a 2003 DC
Summary: 2 errors when joining a 2003 DC
Alias: None
Product: realmd
Classification: Unclassified
Component: adcli (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Stef Walter
QA Contact:
Depends on:
Reported: 2013-07-18 21:16 UTC by Laurent Bigonville
Modified: 2016-05-20 13:22 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Log (2.43 KB, text/plain)
2013-07-18 21:16 UTC, Laurent Bigonville
Test disabling AES (438 bytes, patch)
2013-07-19 10:53 UTC, Stef Walter
Details | Splinter Review
ldapsearch output (611 bytes, text/plain)
2013-07-19 18:18 UTC, Laurent Bigonville
Log2 (2.38 KB, text/plain)
2013-07-19 18:29 UTC, Laurent Bigonville
Don't try to set encryption types on Windows 2003 and earlier (7.70 KB, patch)
2013-07-23 10:43 UTC, Stef Walter
Details | Splinter Review
Log with patch (2.16 KB, text/plain)
2013-08-02 10:13 UTC, Laurent Bigonville

Description Laurent Bigonville 2013-07-18 21:16:43 UTC
Created attachment 82638 [details]


When trying to join a domain on my windows 2003 test DC, I'm getting the following error:

 ! Couldn't set encryption types on computer account: CN=FORNOST,CN=Computers,DC=bigon,DC=be: 00000057: LdapErr: DSID-0C090A85, comment: Error in attribute conversion operation, data 0, vece


 ! Couldn't set service principals on computer account CN=FORNOST,CN=Computers,DC=bigon,DC=be: 00002083: AtrErr: DSID-031510B7, #1:
	0: 00002083: DSID-031510B7, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303 (servicePrincipalName)
Comment 1 Stef Walter 2013-07-19 10:53:05 UTC
Interesting. Are you able to do a bit of debugging on this?

I'm interested in two things:

 a) Does commenting out the AES encryption types in
    adcli_enroll_get_keytab_enctypes() solve the first warning? Attaching patch
    which does this. Could you try it out?

 b) What servicePrincipalName attributes are set on the new computer account?
    You should be able to use commands like this:
    $ kinit Administrator@BIGON.DE
    $ ldapsearch -Y GSSAPI -H ldap://bigon-e80ef7e8e.bigon.be/ \
         -b CN=FORNOST,CN=Computers,DC=bigon,DC=be -s base 
         "(objectClass=*)" servicePrincipalName
Comment 2 Stef Walter 2013-07-19 10:53:51 UTC
Created attachment 82677 [details] [review]
Test disabling AES

Patch to try out
Comment 3 Laurent Bigonville 2013-07-19 18:18:26 UTC
Created attachment 82702 [details]
ldapsearch output
Comment 4 Laurent Bigonville 2013-07-19 18:29:28 UTC
Created attachment 82703 [details]

This is with the patch, looks the same
Comment 5 Stef Walter 2013-07-22 12:20:38 UTC
Do you know what the exact version of your DC, and what is the compatibility level of your domain?

Is this a test domain? Am I able to temporarily authenticate against it in order to try to solve this problem?
Comment 6 Laurent Bigonville 2013-07-22 15:50:03 UTC

It's a win server 2003 SP2 standard edition

Well it's a VM running on my machine just for testing purpose
Comment 7 Stef Walter 2013-07-23 10:43:26 UTC
Created attachment 82861 [details] [review]
Don't try to set encryption types on Windows 2003 and earlier

Could you try out this patch?
Comment 8 Laurent Bigonville 2013-08-02 10:13:34 UTC
Created attachment 83522 [details]
Log with patch


Please find here the output of adcli with the patch from comment #7

The first warning about the encryption type is now gone

But the second one about the "service principals" is still present (but I guess this was expected)
Comment 9 Stef Walter 2013-08-07 08:11:26 UTC
Attachment 82861 [details] pushed as 2de8982 - Don't try to set encryption types on Windows 2003 and earlier
Comment 10 Sumit Bose 2016-05-19 16:24:45 UTC
Hi Stef,

are you still waiting for a confirmation that the issue with 2003 is gone or can this ticket be closed?
Comment 11 Stef Walter 2016-05-20 12:15:15 UTC
Yup, I had originally thought to wait on confirmation, but do you think we should just go ahead and merge this? If so, would you have a chance to review?
Comment 12 Sumit Bose 2016-05-20 12:53:39 UTC
It is already committed as 2de89825f40352ffdebd1e62ddcd4b74e89596e1 :-)

Nevertheless the patch looks good. I would have used bool as a return value for adcli_conn_server_has_capability() but I guess this is a personal preference :-)

The evaluation is in agreement with https://msdn.microsoft.com/en-us/library/cc223359.aspx and I guess it can be expected that LDAP_CAP_ACTIVE_DIRECTORY_V60_OID will be set in all upcoming Windows versions as well. So ACK to the patch.
Comment 13 Stef Walter 2016-05-20 13:22:48 UTC
> It is already committed as 2de89825f40352ffdebd1e62ddcd4b74e89596e1 :-)

Oh good. Then lets close this.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.