Discussion:
[PATCH] Add external-schema directory
William Brown via samba-technical
2018-04-30 03:27:50 UTC
Permalink
Hi,

There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel, we
should ship some useful schema that we know is correct and able to
extend the directory for broader unix application use.

The two schemas in this patch are for ssh public key storage in LDAP,
and nsUniqueId compatability for migrations from SUN-DS/389 Directory
Server applications.

Thanks,

William
Alexander Bokovoy via samba-technical
2018-04-30 05:43:43 UTC
Permalink
Hi,
Post by William Brown via samba-technical
Hi,
There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel, we
should ship some useful schema that we know is correct and able to
extend the directory for broader unix application use.
How would you propose installing them? The patch doesn't address this
part other than README document, so how they would be installed? You'd
need to add bit of bld.INSTALL_WILDCARD() to the
source4/setup/wscript_build

Perhaps, DC=.. parts need to be changed to be consistent with
schema_samba4.ldif which uses ${SCHEMADN}.

Also, it may be good to provide a 'samba-tool' subcommand that plugs
into some of the code in python/samba/provision.

For schemaIDGUID would be good to add a comment above the attribute
definition that has the GUID in a readable form.
Post by William Brown via samba-technical
The two schemas in this patch are for ssh public key storage in LDAP,
and nsUniqueId compatability for migrations from SUN-DS/389 Directory
Server applications.
Thanks,
William
From e5f71309b6c2aaf4cc395cd86de1161a83e59167 Mon Sep 17 00:00:00 2001
Date: Mon, 30 Apr 2018 15:23:14 +1200
Subject: [PATCH] source4/setup/external-schema: Add ns compat and sshpubkey
Add externally provided schema files that can be applied to a domain. This
prevents admins needing to apply "random ldifs" from the internet. The two
external schemas are for sshpublic key storage in LDAP, and the second is
a 389 Directory Server compatability attribute for UUID mapping.
---
source4/setup/external-schema/README | 6 ++++++
source4/setup/external-schema/README.txt | 11 +++++++++++
source4/setup/external-schema/ns.ldif | 29 ++++++++++++++++++++++++++++
source4/setup/external-schema/sshpubkey.ldif | 29 ++++++++++++++++++++++++++++
4 files changed, 75 insertions(+)
create mode 100644 source4/setup/external-schema/README
create mode 100644 source4/setup/external-schema/README.txt
create mode 100644 source4/setup/external-schema/ns.ldif
create mode 100644 source4/setup/external-schema/sshpubkey.ldif
diff --git a/source4/setup/external-schema/README b/source4/setup/external-schema/README
new file mode 100644
index 00000000000..a8416b94792
--- /dev/null
+++ b/source4/setup/external-schema/README
@@ -0,0 +1,6 @@
+This is a set of external LDIF schemas that are useful - but not installed
+by default.
+
+They exist so that rather than applying random internet LDIF's we can guide
+people to use these instead.
+
diff --git a/source4/setup/external-schema/README.txt b/source4/setup/external-schema/README.txt
new file mode 100644
index 00000000000..844246d4dab
--- /dev/null
+++ b/source4/setup/external-schema/README.txt
@@ -0,0 +1,11 @@
+This is a set of external LDIF schemas that are useful - but not installed
+by default.
+
+They exist so that rather than applying random internet LDIF's we can guide
+people to use these instead.
+
+To apply these, you need to copy them and replace 'DC=X' with your domain DN.
+
+They can then be applied with ldapmodify -f <name>.ldif. You will need to
+authenticate with an account that is a member of Schema Admins.
+
diff --git a/source4/setup/external-schema/ns.ldif b/source4/setup/external-schema/ns.ldif
new file mode 100644
index 00000000000..caeb584d206
--- /dev/null
+++ b/source4/setup/external-schema/ns.ldif
@@ -0,0 +1,29 @@
+
+dn: CN=nsUniqueId,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: attributeSchema
+attributeID: 2.16.840.1.113730.3.1.542
+cn: nsUniqueId
+name: nsUniqueId
+lDAPDisplayName: nsUniqueId
+description: MANDATORY: nsUniqueId compatability
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: TRUE
+searchFlags: 9
+
+dn: CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: classSchema
+governsID: 2.16.840.1.113730.3.2.334
+cn: nsOrgPerson
+name: nsOrgPerson
+description: MANDATORY: Netscape DS compat person
+lDAPDisplayName: nsOrgPerson
+subClassOf: top
+objectClassCategory: 3
+defaultObjectCategory: CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+mayContain: nsUniqueId
+
diff --git a/source4/setup/external-schema/sshpubkey.ldif b/source4/setup/external-schema/sshpubkey.ldif
new file mode 100644
index 00000000000..439feda8e1a
--- /dev/null
+++ b/source4/setup/external-schema/sshpubkey.ldif
@@ -0,0 +1,29 @@
+dn: CN=sshPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: attributeSchema
+attributeID: 1.3.6.1.4.1.24552.500.1.1.1.13
+schemaIDGUID:: fHCvUrxcsUSrYRq8nUvw5Q==
+cn: sshPublicKey
+name: sshPublicKey
+lDAPDisplayName: sshPublicKey
+description: MANDATORY: OpenSSH Public key
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: FALSE
+
+dn: CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: classSchema
+governsID: 1.3.6.1.4.1.24552.500.1.1.2.0
+schemaIDGUID:: yfKd3707f0qnSxgXE9qYeA==
+cn: ldapPublicKey
+name: ldapPublicKey
+description: MANDATORY: OpenSSH LPK objectclass
+lDAPDisplayName: ldapPublicKey
+subClassOf: top
+objectClassCategory: 3
+defaultObjectCategory: CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+mayContain: sshPublicKey
+
--
2.14.3
--
/ Alexander Bokovoy
Rowland Penny via samba-technical
2018-04-30 06:58:06 UTC
Permalink
On Mon, 30 Apr 2018 08:43:43 +0300
Post by Alexander Bokovoy via samba-technical
Hi,
Post by William Brown via samba-technical
Hi,
There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel
Why not, Windows does.

Rowland
Post by Alexander Bokovoy via samba-technical
, we
Post by William Brown via samba-technical
should ship some useful schema that we know is correct and able to
extend the directory for broader unix application use.
How would you propose installing them? The patch doesn't address this
part other than README document, so how they would be installed? You'd
need to add bit of bld.INSTALL_WILDCARD() to the
source4/setup/wscript_build
Perhaps, DC=.. parts need to be changed to be consistent with
schema_samba4.ldif which uses ${SCHEMADN}.
Also, it may be good to provide a 'samba-tool' subcommand that plugs
into some of the code in python/samba/provision.
For schemaIDGUID would be good to add a comment above the attribute
definition that has the GUID in a readable form.
Post by William Brown via samba-technical
The two schemas in this patch are for ssh public key storage in
LDAP, and nsUniqueId compatability for migrations from SUN-DS/389
Directory Server applications.
Thanks,
William
From e5f71309b6c2aaf4cc395cd86de1161a83e59167 Mon Sep 17 00:00:00
Date: Mon, 30 Apr 2018 15:23:14 +1200
Subject: [PATCH] source4/setup/external-schema: Add ns compat and sshpubkey
Add externally provided schema files that can be applied to a
domain. This prevents admins needing to apply "random ldifs" from
the internet. The two external schemas are for sshpublic key
storage in LDAP, and the second is a 389 Directory Server
compatability attribute for UUID mapping.
---
source4/setup/external-schema/README | 6 ++++++
source4/setup/external-schema/README.txt | 11 +++++++++++
source4/setup/external-schema/ns.ldif | 29
++++++++++++++++++++++++++++
source4/setup/external-schema/sshpubkey.ldif | 29
++++++++++++++++++++++++++++ 4 files changed, 75 insertions(+)
create mode 100644 source4/setup/external-schema/README create mode
100644 source4/setup/external-schema/README.txt create mode 100644
source4/setup/external-schema/ns.ldif create mode 100644
source4/setup/external-schema/sshpubkey.ldif
diff --git a/source4/setup/external-schema/README
b/source4/setup/external-schema/README new file mode 100644
index 00000000000..a8416b94792
--- /dev/null
+++ b/source4/setup/external-schema/README
@@ -0,0 +1,6 @@
+This is a set of external LDIF schemas that are useful - but not
installed +by default.
+
+They exist so that rather than applying random internet LDIF's we
can guide +people to use these instead.
+
diff --git a/source4/setup/external-schema/README.txt
b/source4/setup/external-schema/README.txt new file mode 100644
index 00000000000..844246d4dab
--- /dev/null
+++ b/source4/setup/external-schema/README.txt
@@ -0,0 +1,11 @@
+This is a set of external LDIF schemas that are useful - but not
installed +by default.
+
+They exist so that rather than applying random internet LDIF's we
can guide +people to use these instead.
+
+To apply these, you need to copy them and replace 'DC=X' with your
domain DN. +
+They can then be applied with ldapmodify -f <name>.ldif. You will
need to +authenticate with an account that is a member of Schema
Admins. +
diff --git a/source4/setup/external-schema/ns.ldif
b/source4/setup/external-schema/ns.ldif new file mode 100644
index 00000000000..caeb584d206
--- /dev/null
+++ b/source4/setup/external-schema/ns.ldif
@@ -0,0 +1,29 @@
+
CN=nsUniqueId,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add +objectClass: top
+objectClass: attributeSchema
+attributeID: 2.16.840.1.113730.3.1.542
+cn: nsUniqueId
+name: nsUniqueId
+lDAPDisplayName: nsUniqueId
+description: MANDATORY: nsUniqueId compatability
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: TRUE
+searchFlags: 9
+
CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add +objectClass: top
+objectClass: classSchema
+governsID: 2.16.840.1.113730.3.2.334
+cn: nsOrgPerson
+name: nsOrgPerson
+description: MANDATORY: Netscape DS compat person
+lDAPDisplayName: nsOrgPerson
+subClassOf: top
+objectClassCategory: 3
CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+mayContain: nsUniqueId +
diff --git a/source4/setup/external-schema/sshpubkey.ldif
b/source4/setup/external-schema/sshpubkey.ldif new file mode 100644
index 00000000000..439feda8e1a
--- /dev/null
+++ b/source4/setup/external-schema/sshpubkey.ldif
@@ -0,0 +1,29 @@
CN=sshPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+changetype: add +objectClass: top
+objectClass: attributeSchema
+attributeID: 1.3.6.1.4.1.24552.500.1.1.1.13
+schemaIDGUID:: fHCvUrxcsUSrYRq8nUvw5Q==
+cn: sshPublicKey
+name: sshPublicKey
+lDAPDisplayName: sshPublicKey
+description: MANDATORY: OpenSSH Public key
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: FALSE
+
CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+changetype: add +objectClass: top
+objectClass: classSchema
+governsID: 1.3.6.1.4.1.24552.500.1.1.2.0
+schemaIDGUID:: yfKd3707f0qnSxgXE9qYeA==
+cn: ldapPublicKey
+name: ldapPublicKey
+description: MANDATORY: OpenSSH LPK objectclass
+lDAPDisplayName: ldapPublicKey
+subClassOf: top
+objectClassCategory: 3
CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=net,DC=au
+mayContain: sshPublicKey +
--
2.14.3
William Brown via samba-technical
2018-04-30 21:39:34 UTC
Permalink
On Mon, 2018-04-30 at 07:58 +0100, Rowland Penny via samba-technical
Post by Rowland Penny via samba-technical
On Mon, 30 Apr 2018 08:43:43 +0300
g>
Hi,
Post by William Brown via samba-technical
Hi,
There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel
Why not, Windows does.
Sorry, I don't believe this is an appropriate attitude in response to
my proposal.

If people want that experience then they are free to

* Choose not to utilise this resource - I'm not proposing that the
schema is applied by default.
* Continue to use windows DC's - again choosing not to use this option.

There is a broader picture here however. I am trying to consider this
as an accesibility change that improves the experience for
administrators interested in the Unix integration functionality of
Samba DC's. Making samba "easier to use" than the Windows DC option is
an attractive change (to me personally) as it will help to encourage
people to utilise it in different situations than people classically
have considered. For example, by making it simpler to provide ssh
public key distribution schema, people can use SUSE/RHEL/Debian with
SSSD, and enjoy the benefits of a single identity store (Samba AD) and
the benefits of a unix directory (distributed ssh keys).

As well I'm also looking to this as a migration process. Many business
applications still require and link to certain attributes. In my case
it's nsUniqueId, in others it may be entryUUID, or even ipaUniqueId.
Being able to support these attributes on objects means people can
perform a migration from 389DS/OpenLDAP/IPA to Samba AD, without
breaking their applications UUID links that exist.

This is a change that is looking beyond just "what does Windows do",
but is looking at answering "What is required for Unix to be a first
class client in a Samba AD environment".

Today this is just proposing some schema templates. But in the future I
think that some larger questions of support for things like UUID
generation and compatability should be proposed as a "bonus extra" to
the Samba project.

Who knows - maybe having easily accessible tooling and schema will be
the deciding factor between "Do we keep using windows DCs" or "Maybe we
should use Samba as it's easier".

Thanks,

William
Rowland Penny via samba-technical
2018-05-01 07:38:47 UTC
Permalink
On Tue, 01 May 2018 09:39:34 +1200
Post by William Brown via samba-technical
On Mon, 2018-04-30 at 07:58 +0100, Rowland Penny via samba-technical
Post by Rowland Penny via samba-technical
On Mon, 30 Apr 2018 08:43:43 +0300
Alexander Bokovoy via samba-technical
g>
Hi,
Post by William Brown via samba-technical
Hi,
There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel
Why not, Windows does.
Sorry, I don't believe this is an appropriate attitude in response to
my proposal.
If people want that experience then they are free to
* Choose not to utilise this resource - I'm not proposing that the
schema is applied by default.
* Continue to use windows DC's - again choosing not to use this option.
There is a broader picture here however. I am trying to consider this
as an accesibility change that improves the experience for
administrators interested in the Unix integration functionality of
Samba DC's. Making samba "easier to use" than the Windows DC option is
an attractive change (to me personally) as it will help to encourage
people to utilise it in different situations than people classically
have considered. For example, by making it simpler to provide ssh
public key distribution schema, people can use SUSE/RHEL/Debian with
SSSD, and enjoy the benefits of a single identity store (Samba AD) and
the benefits of a unix directory (distributed ssh keys).
As well I'm also looking to this as a migration process. Many business
applications still require and link to certain attributes. In my case
it's nsUniqueId, in others it may be entryUUID, or even ipaUniqueId.
Being able to support these attributes on objects means people can
perform a migration from 389DS/OpenLDAP/IPA to Samba AD, without
breaking their applications UUID links that exist.
This is a change that is looking beyond just "what does Windows do",
but is looking at answering "What is required for Unix to be a first
class client in a Samba AD environment".
Today this is just proposing some schema templates. But in the future
I think that some larger questions of support for things like UUID
generation and compatability should be proposed as a "bonus extra" to
the Samba project.
Who knows - maybe having easily accessible tooling and schema will be
the deciding factor between "Do we keep using windows DCs" or "Maybe
we should use Samba as it's easier".
Thanks,
William
Provided that what you are proposing can be ignored, I can accept it.

Yes, whilst 'windows does it' isn't really a good argument, you have to
remember that if people want to do things that Samba denies, but
Windows allows, they will just use Windows to do them.

Rowland
William Brown via samba-technical
2018-05-01 21:28:12 UTC
Permalink
Post by Rowland Penny via samba-technical
Post by William Brown via samba-technical
Who knows - maybe having easily accessible tooling and schema will be
the deciding factor between "Do we keep using windows DCs" or "Maybe
we should use Samba as it's easier".
Thanks,
William
Provided that what you are proposing can be ignored, I can accept it.
Yes, whilst 'windows does it' isn't really a good argument, you have to
remember that if people want to do things that Samba denies, but
Windows allows, they will just use Windows to do them.
Hey there,

A better way to have had this conversation would have been to ask what
I was trying to achieve - what was my end goal. That would have allowed
a better discussion to take place. Kindness and empathy towards
contributors (especially new ones like myself) is really important to
grow the developer community of a project, so please keep this in mind
for the future.

My response clearly states that I want to layer something optionally
ontop of the ADDS functionality. I do not understand how you have
concluded that I intended to deny or remove some functionality ("if
people want to do things that Samba denies").

I hope that in the future we can have a better, positive discussion
about design goals and objectives for the project.

Thanks!

William

William Brown via samba-technical
2018-04-30 22:24:54 UTC
Permalink
On Mon, 2018-04-30 at 08:43 +0300, Alexander Bokovoy via samba-
Post by Alexander Bokovoy via samba-technical
Hi,
Post by William Brown via samba-technical
Hi,
There are a small number of useful external schemas that we should
provide. Instead of letting admins pull these from the internel, we
should ship some useful schema that we know is correct and able to
extend the directory for broader unix application use.
How would you propose installing them? The patch doesn't address this
part other than README document, so how they would be installed? You'd
need to add bit of bld.INSTALL_WILDCARD() to the
source4/setup/wscript_build
I think I did? They install for me?

find /usr/local/samba | grep -i external
/usr/local/samba/share/setup/external-schema
/usr/local/samba/share/setup/external-schema/README.txt
/usr/local/samba/share/setup/external-schema/ns.ldif
/usr/local/samba/share/setup/external-schema/sshpubkey.ldif

Maybe you mean application of the schema to the cn=schema partition?
Post by Alexander Bokovoy via samba-technical
Perhaps, DC=.. parts need to be changed to be consistent with
schema_samba4.ldif which uses ${SCHEMADN}.
This is a good idea. I'll update this.

Andrew Bartlett (whom I am seeing this week) has suggested to me in
person that I extend this to cover the other UUID types that I
mentioned (entryUUID notably). We are discussing some ideas about an
LDB module that could generate these also, but the main goal would be
migration compatability. Of course, given how "static" AD schema is in
contrast to 389ds/ipa, I'm worried about going too far since we can not
easily back-out of a change. We also have to consider "schema mods on
upgrade too" in case we extend this also.
Post by Alexander Bokovoy via samba-technical
Also, it may be good to provide a 'samba-tool' subcommand that plugs
into some of the code in python/samba/provision.
That was my next idea. I was however following the "break the patches
up idea" :)

I have a stack of commands still under review by people, so I'm a
little hesitant to "keep piling on code" until they are accepted. I'd
really want this to be part of the schema command. In my mind I think
something like this would be a good work flow

samba-tool schema external list
<list of external schemas we can add>
samba-tool schema external show <name>
<cat the content of the ldif>
samba-tool schema external apply <name>
<apply the schema to the directory>

The benefit of "apply" is that we can do the correct appending of
auxilaryClass to the person object class - we can't do it in the ldif
because you need to know all CURRENT auxclass values for the ldap mod,
so having this in a tool makes it significantly easier and safer.

What do you think of this?

Another suggestion from Andrew was to have an "extended" mode in
provision that automatically applies this schema compatability. Kind of
like "DC++" mode that has some extra unix integration goodies. But I
think that requires me to document what I have in my mind about
integration options, and needs some planning and understanding. We
can't just rush into that one.
Post by Alexander Bokovoy via samba-technical
For schemaIDGUID would be good to add a comment above the attribute
definition that has the GUID in a readable form.
Yes, this is a good idea. I'll add that.
Post by Alexander Bokovoy via samba-technical
Post by William Brown via samba-technical
The two schemas in this patch are for ssh public key storage in LDAP,
and nsUniqueId compatability for migrations from SUN-DS/389
Directory
Server applications.
Thanks,
William
From e5f71309b6c2aaf4cc395cd86de1161a83e59167 Mon Sep 17 00:00:00 2001
Date: Mon, 30 Apr 2018 15:23:14 +1200
Subject: [PATCH] source4/setup/external-schema: Add ns compat and sshpubkey
Add externally provided schema files that can be applied to a domain. This
prevents admins needing to apply "random ldifs" from the internet. The two
external schemas are for sshpublic key storage in LDAP, and the second is
a 389 Directory Server compatability attribute for UUID mapping.
---
source4/setup/external-schema/README | 6 ++++++
source4/setup/external-schema/README.txt | 11 +++++++++++
source4/setup/external-schema/ns.ldif | 29
++++++++++++++++++++++++++++
source4/setup/external-schema/sshpubkey.ldif | 29
++++++++++++++++++++++++++++
4 files changed, 75 insertions(+)
create mode 100644 source4/setup/external-schema/README
create mode 100644 source4/setup/external-schema/README.txt
create mode 100644 source4/setup/external-schema/ns.ldif
create mode 100644 source4/setup/external-schema/sshpubkey.ldif
diff --git a/source4/setup/external-schema/README
b/source4/setup/external-schema/README
new file mode 100644
index 00000000000..a8416b94792
--- /dev/null
+++ b/source4/setup/external-schema/README
@@ -0,0 +1,6 @@
+This is a set of external LDIF schemas that are useful - but not installed
+by default.
+
+They exist so that rather than applying random internet LDIF's we can guide
+people to use these instead.
+
diff --git a/source4/setup/external-schema/README.txt
b/source4/setup/external-schema/README.txt
new file mode 100644
index 00000000000..844246d4dab
--- /dev/null
+++ b/source4/setup/external-schema/README.txt
@@ -0,0 +1,11 @@
+This is a set of external LDIF schemas that are useful - but not installed
+by default.
+
+They exist so that rather than applying random internet LDIF's we can guide
+people to use these instead.
+
+To apply these, you need to copy them and replace 'DC=X' with your domain DN.
+
+They can then be applied with ldapmodify -f <name>.ldif. You will need to
+authenticate with an account that is a member of Schema Admins.
+
diff --git a/source4/setup/external-schema/ns.ldif
b/source4/setup/external-schema/ns.ldif
new file mode 100644
index 00000000000..caeb584d206
--- /dev/null
+++ b/source4/setup/external-schema/ns.ldif
@@ -0,0 +1,29 @@
+
CN=nsUniqueId,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: attributeSchema
+attributeID: 2.16.840.1.113730.3.1.542
+cn: nsUniqueId
+name: nsUniqueId
+lDAPDisplayName: nsUniqueId
+description: MANDATORY: nsUniqueId compatability
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: TRUE
+searchFlags: 9
+
CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+changetype: add
+objectClass: top
+objectClass: classSchema
+governsID: 2.16.840.1.113730.3.2.334
+cn: nsOrgPerson
+name: nsOrgPerson
+description: MANDATORY: Netscape DS compat person
+lDAPDisplayName: nsOrgPerson
+subClassOf: top
+objectClassCategory: 3
CN=nsOrgPerson,CN=Schema,CN=Configuration,DC=blackhats,DC=net,DC=au
+mayContain: nsUniqueId
+
diff --git a/source4/setup/external-schema/sshpubkey.ldif
b/source4/setup/external-schema/sshpubkey.ldif
new file mode 100644
index 00000000000..439feda8e1a
--- /dev/null
+++ b/source4/setup/external-schema/sshpubkey.ldif
@@ -0,0 +1,29 @@
CN=sshPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=n
et,DC=au
+changetype: add
+objectClass: top
+objectClass: attributeSchema
+attributeID: 1.3.6.1.4.1.24552.500.1.1.1.13
+schemaIDGUID:: fHCvUrxcsUSrYRq8nUvw5Q==
+cn: sshPublicKey
+name: sshPublicKey
+lDAPDisplayName: sshPublicKey
+description: MANDATORY: OpenSSH Public key
+attributeSyntax: 2.5.5.10
+oMSyntax: 4
+isSingleValued: FALSE
+
CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=
net,DC=au
+changetype: add
+objectClass: top
+objectClass: classSchema
+governsID: 1.3.6.1.4.1.24552.500.1.1.2.0
+schemaIDGUID:: yfKd3707f0qnSxgXE9qYeA==
+cn: ldapPublicKey
+name: ldapPublicKey
+description: MANDATORY: OpenSSH LPK objectclass
+lDAPDisplayName: ldapPublicKey
+subClassOf: top
+objectClassCategory: 3
CN=ldapPublicKey,CN=Schema,CN=Configuration,DC=adt,DC=blackhats,DC=
net,DC=au
+mayContain: sshPublicKey
+
--
2.14.3
Continue reading on narkive:
Loading...