[Samba] Failed to modify SPNs on error in module acl: Constraint violation during LDB_MODIFY (19)

[Markus Dellermann]

Hi,

sometimes I see following in the logs:
/source4/rpc_server/drsuapi/writespn.c:234(dcesrv_drsuapi_DsWriteAccountSpn)
Failed to modify SPNs on
CN=PCNAME,CN=Computers,DC=DOMAIN,DC=NAME,DC=NAME,DC=de: error in module acl:
Constraint violation during LDB_MODIFY (19)

In the net i found this "explanation":

"LDAP_CONSTRAINT_VIOLATION
Indicates that the attribute value specified in a modify, add, or modify DN
operation violates constraints placed on the attribute. The constraint can be
one of size or content (string only, no binary)."

Hm, is this triggerd by dns-updates?
I see this only with two clients
How can I "debug" this ?

I am using samba 4.3.4 with bind-dlz
clients are win7

Thank you for your thoughts!

Markus

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Adam Tauno Williams]

On Tue, 2016-02-02 at 23:38 +0100, Markus Dellermann wrote:
> sometimes I see following in the logs:
> /source4/rpc_server/drsuapi/writespn.c:234(dcesrv_drsuapi_DsWriteAcco
> untSpn)
> Failed to modify SPNs on
> CN=PCNAME,CN=Computers,DC=DOMAIN,DC=NAME,DC=NAME,DC=de: error in
> module acl:
> Constraint violation during LDB_MODIFY (19)

I am seeing a very similar message - Failed to modify SPNs on
CN=TERRINE-WHITE,OU=Terminal Servers,DC=example,DC=com: error in module
acl: Constraint violation (19)

> In the net i found this "explanation":
>
> "LDAP_CONSTRAINT_VIOLATION
> Indicates that the attribute value specified in a modify, add, or
> modify DN
> operation violates constraints placed on the attribute. The
> constraint can be
> one of size or content (string only, no binary)."
>
> Hm, is this triggerd by dns-updates?
> I see this only with two clients
> How can I "debug" this ?
>
> I am using samba 4.3.4 with bind-dlz
> clients are win7
>
> Thank you for your thoughts!
>
> Markus
>
--

Adam Tauno Williams <mailto:awil...@whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

[mathias dufresne]

Hi all,

SPN = servicePrincipalName

A simple search returning all servicePrincipalName declared in your AD:
ldbsearch -H $sam serviceprincipalname=* serviceprincipalname

An extract from result concerning a lambda client:
# record 41
dn: CN=win-client345,OU=Machines,DC=ad,DC=domain,DC=tld
servicePrincipalName: HOST/MB38W746-0009
servicePrincipalName: HOST/MB38W746-0009.ad.domain.tld
servicePrincipalName: TERMSRV/MB38W746-0009.ad.domain.tld
servicePrincipalName: TERMSRV/MB38W746-0009

I would start checking rights using security tab of your client machine
into ADUC tool to verify "SELF" is well configured (comparing with some
other machine not generating these logs).

When this kind of message happens? When you add new client or when client
boots or randomly?

Not sure that helps, I tried ;)

[Markus Dellermann]

Am Donnerstag, 10. März 2016, 10:41:34 CET schrieb mathias dufresne:
Hi, Mathias and all
thank you for your answer.

> Hi all,
>
> SPN = servicePrincipalName
>
> A simple search returning all servicePrincipalName declared in your AD:
> ldbsearch -H $sam serviceprincipalname=* serviceprincipalname
>

For me:
ldbsearch -H
/var/lib/samba/private/sam.ldb serviceprincipalname=* serviceprincipalname

> An extract from result concerning a lambda client:
> # record 41
> dn: CN=win-client345,OU=Machines,DC=ad,DC=domain,DC=tld
> servicePrincipalName: HOST/MB38W746-0009
> servicePrincipalName: HOST/MB38W746-0009.ad.domain.tld
> servicePrincipalName: TERMSRV/MB38W746-0009.ad.domain.tld
> servicePrincipalName: TERMSRV/MB38W746-0009
>

An affected client:
# record 6
dn: CN=MACHINE1,CN=Computers,DC=ad,DC=domain,DC=domain,DC=tld
servicePrincipalName: HOST/ MACHINE1.ad.domain.domain.tld
servicePrincipalName: RestrictedKrbHost/MACHINE1.ad.domain.domain.tld
servicePrincipalName: HOST/MACHINE1
servicePrincipalName: RestrictedKrbHost/MACHINE1
servicePrincipalName: TERMSRV/MACHINE1.ad.domain.domain.tld
servicePrincipalName: TERMSRV/MACHINE1

Not affected:
# record 19
dn: CN=MACHINE2,CN=Computers,DC=ad,DC=domain,DC=domain,DC=tld
servicePrincipalName: HOST/MACHINE2
servicePrincipalName: HOST/MACHINE2.ad.domain.domain.tld
servicePrincipalName: TERMSRV/MACHINE2.ad.domain.domain.tld
servicePrincipalName: TERMSRV/MACHINE2

Not affected:
# record 8
dn: CN=MACHINE3,CN=Computers,DC=ad,DC=domain,DC=domain,DC=tld
servicePrincipalName: HOST/MACHINE3
servicePrincipalName: HOST/MACHINE3.ad.domain.domain.tld
servicePrincipalName: TERMSRV/MACHINE3.ad.domain.domain.tld
servicePrincipalName: TERMSRV/MACHINE3
servicePrincipalName: RestrictedKrbHost/MACHINE3.ad.domain.domain.tld
servicePrincipalName: RestrictedKrbHost/MACHINE3

I see no big differences..
maybe except
"servicePrincipalName: RestrictedKrbHost/MACHINE1.ad.domain.domain.tld"

Does the entry order matters?

> I would start checking rights using security tab of your client machine
> into ADUC tool to verify "SELF" is well configured (comparing with some
> other machine not generating these logs).
>

No differences between the rights, but in "Attribut-Editor"
Affected Clients have not set:
- displayName
- uidNumber

> When this kind of message happens? When you add new client or when client
> boots or randomly?
>

For me it only occurs, when two of our clients boots.,

> Not sure that helps, I tried ;)
>

Thank you!
(After holiday i will try to look deeper)

Markus

[Markus Dellermann]

Hi again,

Am Montag, 14. März 2016, 00:44:47 CET schrieb Markus Dellermann:
> Am Donnerstag, 10. März 2016, 10:41:34 CET schrieb mathias dufresne:
> Hi, Mathias and all
> thank you for your answer.
>
> > Hi all,
> >
> > SPN = servicePrincipalName
> >
> > A simple search returning all servicePrincipalName declared in your AD:
> > ldbsearch -H $sam serviceprincipalname=* serviceprincipalname
>
> For me:
> ldbsearch -H
> /var/lib/samba/private/sam.ldb serviceprincipalname=* serviceprincipalname
>

[...]
Thank you again for the hint!

With "loglevel=10" i found the affected servicePrincipalName:

ldb: ldb_trace_request: MODIFY
dn: CN=PCNAME,CN=Computers,DC=...
changetype: modify
add: servicePrincipalName
servicePrincipalName: MSSQLSvc/PCNAME.domain.domain.domain.de:DATEV_DBENGIN
E
-
control: 1.2.840.113556.1.4.1413 crit:0 data:no

[2016/03/24 01:01:45.075853, 10, pid=32023, effective(0, 0), real(0, 0)] ../
source4/dsdb/samdb/ldb_modules/acl.c:1055(acl_modify)
ldb:acl_modify: servicePrincipalName

[2016/03/24 01:01:45.076866, 10, pid=32023, effective(0, 0), real(0, 0),
class=ldb] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug)
[...]
ldb: ldb_asprintf/set_errstring: error in module acl: Constraint violation
during LDB_MODIFY (19)
[...]
ldb: ldb_trace_next_request: (tdb)->del_transaction
[2016/03/24 01:01:45.077191, 0, pid=32023, effective(0, 0), real(0, 0)] ../
source4/rpc_server/drsuapi/writespn.c:234(dcesrv_drsuapi_DsWriteAccountSpn)
Failed to modify SPNs on CN=PCNAME,CN=Computers,DC=DOMAIN,DC=...: error in

module acl: Constraint violation during LDB_MODIFY (19)

[2016/03/24 01:01:45.079992, 1, pid=32023, effective(0, 0), real(0, 0)] ../
librpc/ndr/ndr.c:439(ndr_print_function_debug)
drsuapi_DsWriteAccountSpn: struct drsuapi_DsWriteAccountSpn
out: struct drsuapi_DsWriteAccountSpn
level_out : *
level_out : 0x00000001 (1)
res : *
res : union
drsuapi_DsWriteAccountSpnResult(case 1)
res1: struct drsuapi_DsWriteAccountSpnResult1
status : WERR_ACCESS_DENIED
result : WERR_OK

I have two clients with installed Datev -Software / local SQL-Server with this
Problem

Does SQL-Server have wrong Permissions, or is it a general Problem?

Greetings

Markus

[mathias dufresne]

Hi,

I'm glad that helped you : )

About SPN, I found that link few days ago:
https://adsecurity.org/?page_id=183
It tries to list the string values available usable for SPN.

And it gives also that link:
http://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spns-setspn-syntax-setspn-exe.aspx
That one is a technet paper to explain SPNs.

I tried to read it but for now I wasn't able to fully understand it (more
specifically to understand how I would re-use these concepts for my needs).

Anyway that second link describe SPN syntax as follow:

*serviceclass/host:port servicename*

*serviceclass* and *host* are required, but *port* and *service* name are
optional. The colon between *host* and *port* is only required when a *port*
is present.

According to that and because I have no idea what is DATEV_DBENGINE

dn: CN=PCNAME,CN=Computers,DC=...
changetype: modify
add: servicePrincipalName

servicePrincipalName: MSSQLSvc/PCNAME.ad-dom.domain.tld:<some port number>

And I would also add a second SPN using NETBIOS name of PCNAME rather than
FQDN, which gives us:

servicePrincipalName: MSSQLSvc/PCNAME:<some port number>

Adding both SPN you have two unique name for your SPN and that SPN is valid
when client requesting that SPN using FQDN and/or Netbios name (or short
name).

Please tell me if you were able to add mentioned SPN and if your issue is
now solved (just for my information ;)

Best regards,

mathias

[Markus Dellermann]

Hi Mathias and all.

Am Donnerstag, 24. März 2016, 13:26:12 CEST schrieb mathias dufresne:
> Hi,
>
> I'm glad that helped you : )
>
> About SPN, I found that link few days ago:
> https://adsecurity.org/?page_id=183
> It tries to list the string values available usable for SPN.
>
> And it gives also that link:
> http://social.technet.microsoft.com/wiki/contents/articles/717.service-princ
> ipal-names-spns-setspn-syntax-setspn-exe.aspx That one is a technet paper to
> explain SPNs.
>
> I tried to read it but for now I wasn't able to fully understand it (more
> specifically to understand how I would re-use these concepts for my needs).
>
> Anyway that second link describe SPN syntax as follow:
>
> *serviceclass/host:port servicename*
>
> *serviceclass* and *host* are required, but *port* and *service* name are
> optional. The colon between *host* and *port* is only required when a *port*
> is present.
>

Thank you for the links & explanation

> According to that and because I have no idea what is DATEV_DBENGINE

"DATEV_DBENGINE"
This is from an Programm called "Datev...", installed local on this pc.
It`s db is stored in local Microsoft-SQL.
But yes, its seems curios, that this is added to the servicePrincipalname
If i understand it`s syntax right, there should be eventually a portnumber,
but maybe this is the local accountname for this service.

> dn: CN=PCNAME,CN=Computers,DC=...
> changetype: modify
> add: servicePrincipalName
> servicePrincipalName: MSSQLSvc/PCNAME.ad-dom.domain.tld:<some port number>
>
> And I would also add a second SPN using NETBIOS name of PCNAME rather than
> FQDN, which gives us:
>
> servicePrincipalName: MSSQLSvc/PCNAME:<some port number>
>
> Adding both SPN you have two unique name for your SPN and that SPN is valid
> when client requesting that SPN using FQDN and/or Netbios name (or short
> name).
>

Adding manually doesn`t work -MS-SQL seems want to modify this entry during
it`s start.

> Please tell me if you were able to add mentioned SPN and if your issue is
> now solved (just for my information ;)
>

With ADUC i have edit extended rights from client machine
and assigned "SELF" rights for reading & write "servicePrincipalName"
This added this required line to sam.ldb:
servicePrincipalName: MSSQLSvc/PCNAME.domain.domain.domain.de:DATEV_DBENGIN
E

Failures in the logs are gone, so this could be the way to fix this.
In terms of security i`m unsure, if it`s a good way, to give an machine rights
to add servicePrincipalNames ?


I am also unclear, why local service should register himself in active-
directory,
The easiest could be to disable this behaviour complete -if possible..
> Best regards,
>
> mathias
>
Greetings

Markus

[mathias dufresne]

I'm not an expert, especially when it comes to servicePrincipalName which I
haven't understood until now but I think it is safe to give an object the
right to modify itself.

If securing is one of your main concern, you could try to remove the
possibility to that account to modify itself, once the servicePrincipalName
is created. Doing that SPN should NOT be removed (no right to remove it)
and authentication should continue to work (SPN is there). You could have
errors into your logs if MS-SQLserv tries to remove SPN at shutdown and/or
add it again at startup.

Anyway, I'm very glad to read I was able to help you a little bit with my
little knowledge on that subject :)

Have a nice day!

mathias

[Markus Dellermann]

Good morning...

Am Dienstag, 29. März 2016, 13:26:30 CEST schrieb mathias dufresne:
> I'm not an expert, especially when it comes to servicePrincipalName which I
> haven't understood until now but I think it is safe to give an object the
> right to modify itself.
>
> If securing is one of your main concern, you could try to remove the
> possibility to that account to modify itself, once the servicePrincipalName
> is created. Doing that SPN should NOT be removed (no right to remove it)
> and authentication should continue to work (SPN is there). You could have
> errors into your logs if MS-SQLserv tries to remove SPN at shutdown and/or
> add it again at startup.
>

About securing, i found this:
http://files.cnblogs.com/files/woodytu/Microsoft.SQL.Server.
2012.Security.Cookbook.Rudi.Bruchez.Packt.2012.pdf

From that the servicePrinipalName-things should work out of the box (with
local system-account):

"...then the SQL Server instance will automatically
register the SPN on the Active Directory when it is started, and it will
unregister it when it is stopped. This is also the case when the service
account is the built-in LocalSystem or the NetworkService local account. These
accounts are shown as the machine name at the AD
and have the rights to register the SPN."

I couldn't find a solution to disable the whole behaviour - i don't need this
service in network.
So i have to live with registering the ServicePricipalNames or with errors in
the logs.
Maybe i generate a serviceaccount for sqlserver, but this all isnt`t very
related to samba...

> Anyway, I'm very glad to read I was able to help you a little bit with my
> little knowledge on that subject :)
>

Thank you for your help
> Have a nice day!
>
And you!
> mathias
>
Greetings
Markus