[GH-ISSUE #67] Feature Request: Arbitrary and Duplicate Text Fields #31

Open
opened 2026-02-27 08:14:46 +03:00 by kerem · 34 comments
Owner

Originally created by @dwmunster on GitHub (Oct 21, 2021).
Original GitHub issue: https://github.com/lldap/lldap/issues/67

Overview

As an LLDAP admin, I would like to be able to define arbitrary text fields that may be repeated to extend the user object schema.

Details

I would like to see the following:

  • the ability to define arbitrary fields with string data
  • the ability to restrict the ability for users to change these fields
  • the ability to have a list or repeated values for the field

Context

I am interested in using LLDAP as a user DB for my mail server and to replace my OpenLDAP instance with something much more manageable. However, my users may have more than one email address assigned to them. Currently, I have that implemented with a repeated mailalias attribute. For example, my user looks something like the following:

dn: uid=user,ou=people,dc=domain,dc=tld
objectClass: mailAccount
objectClass: person
objectClass: uidObject
objectClass: top
uid: user
mail: user@domain.tld
mailenable: TRUE
sn: SN
cn: CN
mailalias: user@domain1.tld
mailalias: user@domain2.tld
mailalias: user2@domain1.tld

Restricting the ability for users to change the mailalias attributes is also crucial to prevent users from impersonating other users and sending mail from arbitrary addresses.

Other use cases include:

  • SSH Public Keys
  • Home directories

Task breakdown:

  • Prepare DB and migration
  • Create Schema data structure + default schema
  • Migrate first and last name to attributes
  • Implement read in the domain
  • Implement read in graphql
  • Implement read in LDAP
  • Implement write in domain
  • Implement write in graphql
  • Implement write in LDAP
  • Implement front-end read/write
  • Implement schema manipulation features
    • domain
    • graphql
    • frontend
  • Implement aliases
    • Query from LDAP
    • create/delete/query domain
    • create/delete/query graphql
    • create/delete/display frontend
  • Custom LDAP object classes
    • backend
    • frontend
Originally created by @dwmunster on GitHub (Oct 21, 2021). Original GitHub issue: https://github.com/lldap/lldap/issues/67 # Overview As an LLDAP admin, I would like to be able to define arbitrary text fields that may be repeated to extend the user object schema. # Details I would like to see the following: * the ability to define arbitrary fields with string data * the ability to restrict the ability for users to change these fields * the ability to have a list or repeated values for the field # Context I am interested in using LLDAP as a user DB for my mail server and to replace my OpenLDAP instance with something much more manageable. However, my users may have more than one email address assigned to them. Currently, I have that implemented with a repeated `mailalias` attribute. For example, my user looks something like the following: ``` dn: uid=user,ou=people,dc=domain,dc=tld objectClass: mailAccount objectClass: person objectClass: uidObject objectClass: top uid: user mail: user@domain.tld mailenable: TRUE sn: SN cn: CN mailalias: user@domain1.tld mailalias: user@domain2.tld mailalias: user2@domain1.tld ``` Restricting the ability for users to change the `mailalias` attributes is also crucial to prevent users from impersonating other users and sending mail from arbitrary addresses. Other use cases include: - SSH Public Keys - Home directories Task breakdown: - [x] Prepare DB and migration - [x] Create Schema data structure + default schema - [x] Migrate first and last name to attributes - [x] Implement read in the domain - [x] Implement read in graphql - [x] Implement read in LDAP - [x] Implement write in domain - [x] Implement write in graphql - [ ] Implement write in LDAP - [x] Implement front-end read/write - [x] Implement schema manipulation features - [x] domain - [x] graphql - [x] frontend - [ ] Implement aliases - [ ] Query from LDAP - [ ] create/delete/query domain - [ ] create/delete/query graphql - [ ] create/delete/display frontend - [x] Custom LDAP object classes - [x] backend - [x] frontend
Author
Owner

@nitnelave commented on GitHub (Oct 22, 2021):

We talked about it a bit on Discord. It'll probably end up getting implemented without a schema: if you request the field, it's there, but otherwise you can't know about it. Moreover, we'll probably only have unstructured strings only, but we'll support repeated or single (if it makes a difference).

In terms of prioritization though, it'll come after the V1 project, so not for a while.

<!-- gh-comment-id:949593977 --> @nitnelave commented on GitHub (Oct 22, 2021): We talked about it a bit on Discord. It'll probably end up getting implemented without a schema: if you request the field, it's there, but otherwise you can't know about it. Moreover, we'll probably only have unstructured strings only, but we'll support repeated or single (if it makes a difference). In terms of prioritization though, it'll come after the V1 project, so not for a while.
Author
Owner

@nitnelave commented on GitHub (Sep 17, 2022):

Here's an RFC for this feature: https://docs.google.com/document/d/1BdizgwX6Pvy5hqH8_HzSg3LCa66tQSDhrTsdhF80ySY/edit?usp=drivesdk

<!-- gh-comment-id:1250029756 --> @nitnelave commented on GitHub (Sep 17, 2022): Here's an RFC for this feature: https://docs.google.com/document/d/1BdizgwX6Pvy5hqH8_HzSg3LCa66tQSDhrTsdhF80ySY/edit?usp=drivesdk
Author
Owner

@Samonitari commented on GitHub (Oct 13, 2022):

Wow!

I was searching for ldap-ui when I stumbled upon this project, which seems pretty awesome.
The only thing stopping me from using this form my family mail/matrix/nextcloud/etc self-host is - mostly - mailAlias attribute.

OTOH, reading the RFC, what use does objectClass filtering will have, if any filtering will always return all users (or groups) if all new items are added for all users (groups)
Seems like adding new, quasi-objectclasses to all users or all groups is quite a limitation, kinda defeats the whole auxilliary class paradigm.
For example, I only host mail for immediate family, meaning they would have PostfixBookMailAccount as auxilliay objectClass, but I host matrix for the larger family.

I have to have filtering based on different objectClass I think... I know it is not intended as a full (Open)LDAP replacement, I am not asking for groupOfUrls, ppolicy and the like.
Could you improve on the RFC possibly?

<!-- gh-comment-id:1277752803 --> @Samonitari commented on GitHub (Oct 13, 2022): Wow! I was searching for [ldap-ui](https://github.com/dnknth/ldap-ui) when I stumbled upon this project, which seems pretty awesome. The only thing stopping me from using this form my family mail/matrix/nextcloud/etc self-host is - mostly - mailAlias attribute. OTOH, reading the RFC, what use does `objectClass` filtering will have, if any filtering will always return all users (or groups) if all new items are added for all users (groups) Seems like adding new, quasi-objectclasses to all users *or* all groups is quite a limitation, kinda defeats the whole auxilliary class paradigm. For example, I only host mail for immediate family, meaning they would have PostfixBookMailAccount as auxilliay objectClass, but I host matrix for the larger family. I have to have filtering based on *different* objectClass I think... I know it is **not** intended as a full (Open)LDAP replacement, I am not asking for `groupOfUrls`, `ppolicy` and the like. Could you improve on the RFC possibly?
Author
Owner

@nitnelave commented on GitHub (Oct 13, 2022):

@Samonitari The objectclass is just so that you can customize the output to match whatever your service expects (e.g. "Oh I only work with PosixUser" -> all the users are now PosixUsers).

The classes in LDAP allow to change the structure of objects, and in LLDAP you only ever have 2 structures, users and groups.

For your usecase, there is a simpler solution: have 2 groups, mailUsers and matrixUsers, and add your users to each group as needed. Then you can filter on these groups.

<!-- gh-comment-id:1277769764 --> @nitnelave commented on GitHub (Oct 13, 2022): @Samonitari The `objectclass` is just so that you can customize the output to match whatever your service expects (e.g. "Oh I only work with PosixUser" -> all the users are now PosixUsers). The classes in LDAP allow to change the _structure_ of objects, and in LLDAP you only ever have 2 structures, users and groups. For your usecase, there is a simpler solution: have 2 groups, `mailUsers` and `matrixUsers`, and add your users to each group as needed. Then you can filter on these groups.
Author
Owner

@Samonitari commented on GitHub (Oct 13, 2022):

For your usecase, there is a simpler solution: have 2 groups, mailUsers and matrixUsers, and add your users to each group as needed. Then you can filter on these groups.

Fair enough.

I am still wrapping my head around a few things to solve differently (or at all) with LLDAP.
Can I reach you in like matrix or something (or could I write an email)?

<!-- gh-comment-id:1277861558 --> @Samonitari commented on GitHub (Oct 13, 2022): > For your usecase, there is a simpler solution: have 2 groups, `mailUsers` and `matrixUsers`, and add your users to each group as needed. Then you can filter on these groups. Fair enough. I am still wrapping my head around a few things to solve differently (or at all) with LLDAP. Can I reach you in like matrix or something (or could I write an email)?
Author
Owner

@Samonitari commented on GitHub (Oct 13, 2022):

BTW, Nextcloud's Mail app have support for getting aliases from a - arbitrarily named - LDAP attribute, which makes handling multiple mail identities for a single mailbox a breeze. You automatically get your identities with your provisioned mail accounts.

Just some context for what this feature means 😜

<!-- gh-comment-id:1277873633 --> @Samonitari commented on GitHub (Oct 13, 2022): BTW, Nextcloud's Mail app have support for getting aliases from a - arbitrarily named - LDAP attribute, which makes handling multiple mail identities for a single mailbox a breeze. You automatically get your identities with your provisioned mail accounts. Just some context for what this feature means 😜
Author
Owner

@nitnelave commented on GitHub (Oct 13, 2022):

Can I reach you in like matrix or something (or could I write an email)?

Feel free to join the Discord :)

<!-- gh-comment-id:1277955041 --> @nitnelave commented on GitHub (Oct 13, 2022): > Can I reach you in like matrix or something (or could I write an email)? Feel free to join the [Discord](https://discord.gg/h5PEdRMNyP) :)
Author
Owner

@blysik commented on GitHub (Apr 5, 2023):

This could also be used to get ssh keys in? I'm currently using glauth for ldap, and rely on it to make ssh public keys available.

<!-- gh-comment-id:1497831409 --> @blysik commented on GitHub (Apr 5, 2023): This could also be used to get ssh keys in? I'm currently using glauth for ldap, and rely on it to make ssh public keys available.
Author
Owner

@nitnelave commented on GitHub (Apr 5, 2023):

Yes, ssh keys should work with this.

On Wed, 5 Apr 2023, 19:00 Bruce Lysik, @.***> wrote:

This could also be used to get ssh keys in? I'm currently using glauth for
ldap, and rely on it to make ssh public keys available.


Reply to this email directly, view it on GitHub
https://github.com/lldap/lldap/issues/67#issuecomment-1497831409, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWNRYACKZ5UVC6MPBHTW7WQK3ANCNFSM5GPAAAZA
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:1498081594 --> @nitnelave commented on GitHub (Apr 5, 2023): Yes, ssh keys should work with this. On Wed, 5 Apr 2023, 19:00 Bruce Lysik, ***@***.***> wrote: > This could also be used to get ssh keys in? I'm currently using glauth for > ldap, and rely on it to make ssh public keys available. > > — > Reply to this email directly, view it on GitHub > <https://github.com/lldap/lldap/issues/67#issuecomment-1497831409>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWNRYACKZ5UVC6MPBHTW7WQK3ANCNFSM5GPAAAZA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
Author
Owner

@abn0mad commented on GitHub (May 9, 2023):

Is there a timeline for this feature?

LLDAP is a truly wonderful project, many thanks for all the team's efforts.
The addition of custom fields, however, is sorely needed for compatibility with other apps such as sftpgo and its external (ldap) authentication hook which requires a sshpublickey and homedir field to operate.

Again, many thanks for the fantastic project and all the effort, very much appreciated. :)

<!-- gh-comment-id:1539348503 --> @abn0mad commented on GitHub (May 9, 2023): Is there a timeline for this feature? LLDAP is a truly wonderful project, many thanks for all the team's efforts. The addition of custom fields, however, is sorely needed for compatibility with other apps such as [sftpgo](https://github.com/drakkan/sftpgo) and its external (ldap) authentication [hook](https://github.com/drakkan/sftpgo/tree/main/examples/ldapauth) which requires a sshpublickey and homedir field to operate. Again, many thanks for the fantastic project and all the effort, very much appreciated. :)
Author
Owner

@nitnelave commented on GitHub (May 9, 2023):

It is the top priority, but I don't have a timeline for my free time :)

If you want to help me build confidence to get started, you can contribute new integration tests for the integrations you care about. See the gitea integration test here: https://github.com/lldap/lldap/blob/main/server/tests/integrations.rs
The idea is to issue the same LDAP queries as the service, and to check that the output is as expected.

This issue requires a fundamental schema and query change, and I don't want to break everything.

<!-- gh-comment-id:1539850950 --> @nitnelave commented on GitHub (May 9, 2023): It is the top priority, but I don't have a timeline for my free time :) If you want to help me build confidence to get started, you can contribute new integration tests for the integrations you care about. See the gitea integration test here: https://github.com/lldap/lldap/blob/main/server/tests/integrations.rs The idea is to issue the same LDAP queries as the service, and to check that the output is as expected. This issue requires a fundamental schema and query change, and I don't want to break everything.
Author
Owner

@abn0mad commented on GitHub (May 9, 2023):

@nitnelave that's totally understandable, and again, thank you for all the hard work on the project. Happy to hear that it is a priority. I hope to include both LLDAP and Kanidm in a series of tutorials and guides that I plan to write on setting up FOSS-based networks and servers. Hopefully, that will attract some organisations to sponsor both projects, as they are well-deserved of more support.

I'll see what I can do with the integration test suggestion, if I can help I surely shall, but it will take me some time to get my head around the code. (Bit of a noob with Rust to be honest : (

Thanks again for reading and answering and all the hard work; hope I can contribute in the near future :)

<!-- gh-comment-id:1539966082 --> @abn0mad commented on GitHub (May 9, 2023): @nitnelave that's totally understandable, and again, thank you for all the hard work on the project. Happy to hear that it is a priority. I hope to include both LLDAP and Kanidm in a series of tutorials and guides that I plan to write on setting up FOSS-based networks and servers. Hopefully, that will attract some organisations to sponsor both projects, as they are well-deserved of more support. I'll see what I can do with the integration test suggestion, if I can help I surely shall, but it will take me some time to get my head around the code. (Bit of a noob with Rust to be honest : ( Thanks again for reading and answering and all the hard work; hope I can contribute in the near future :)
Author
Owner

@nitnelave commented on GitHub (Sep 15, 2023):

For all those watching this issue, as you can see there's been some activity. I created a bunch of tasks to show the roadmap of what's left to implement, you can follow along ;)

<!-- gh-comment-id:1721293985 --> @nitnelave commented on GitHub (Sep 15, 2023): For all those watching this issue, as you can see there's been some activity. I created a bunch of tasks to show the roadmap of what's left to implement, you can follow along ;)
Author
Owner

@nitnelave commented on GitHub (Oct 22, 2023):

Alright, the feature should be functionally complete, but I don't have the frontend updated yet. It's going to be slightly non-trivial, so it'll come little by little.

If there are some brave souls, you can use the graphql API (with the playground or with a client library, or even just curl) to create custom attributes, and add them to users and groups. Any testing would be much appreciated!

With that, a bunch of integrations are unlocked: PAM with sssd, windows with samba, ssh keys stored in LLDAP...
It'll probably take a little effort to figure out the exact configuration, but as a community we should be able to figure it out :)

<!-- gh-comment-id:1774124578 --> @nitnelave commented on GitHub (Oct 22, 2023): Alright, the feature should be functionally complete, but I don't have the frontend updated yet. It's going to be slightly non-trivial, so it'll come little by little. If there are some brave souls, you can use the graphql API (with the playground or with a client library, or even just curl) to create custom attributes, and add them to users and groups. Any testing would be much appreciated! With that, a bunch of integrations are unlocked: PAM with sssd, windows with samba, ssh keys stored in LLDAP... It'll probably take a little effort to figure out the exact configuration, but as a community we should be able to figure it out :)
Author
Owner

@vincentDcmps commented on GitHub (Nov 15, 2023):

Hi thanks for your work, I just try to add an attribute uidNumber and set on user admin via graphql but when I request information via LDAPsearch I can't get this attribute, this function is not implemented yet?

<!-- gh-comment-id:1813161949 --> @vincentDcmps commented on GitHub (Nov 15, 2023): Hi thanks for your work, I just try to add an attribute uidNumber and set on user admin via graphql but when I request information via LDAPsearch I can't get this attribute, this function is not implemented yet?
Author
Owner

@nitnelave commented on GitHub (Nov 16, 2023):

@vincentDcmps can you try specifically requesting the attribute by name in the LDAP query?

<!-- gh-comment-id:1813771703 --> @nitnelave commented on GitHub (Nov 16, 2023): @vincentDcmps can you try specifically requesting the attribute by name in the LDAP query?
Author
Owner

@vincentDcmps commented on GitHub (Nov 16, 2023):

yes see answer of graphql query

{
  "data": {
    "user": {
      "id": "admin",
      "attributes": [
        {
          "name": "uidNumber",
          "value": [
            "10000"
          ]
        }
      ],
      "groups": [
        {
          "id": 1
        },
        {
          "id": 4
        }
      ]
    }
  }
}

and with this

ldapsearch  -H ldap://192.168.1.42:3890 -D uid=admin,ou=people,dc=ducamps,dc=eu -w 'REPLACE_WITH_PASSWORD' uidNumber 
# extended LDIF
#
# LDAPv3
# base <dc=ducamps,dc=eu> (default) with scope subtree
# filter: (objectclass=*)
# requesting: uidNumber
#

# admin, people, ducamps.eu
dn: uid=admin,ou=people,dc=ducamps,dc=eu

# lldap_admin, groups, ducamps.eu
dn: cn=lldap_admin,ou=groups,dc=ducamps,dc=eu

# lldap_password_manager, groups, ducamps.eu
dn: cn=lldap_password_manager,ou=groups,dc=ducamps,dc=eu

# lldap_strict_readonly, groups, ducamps.eu
dn: cn=lldap_strict_readonly,ou=groups,dc=ducamps,dc=eu

# toto, groups, ducamps.eu
dn: cn=toto,ou=groups,dc=ducamps,dc=eu

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQUEAA==
pagedresults: estimate=5 cookie=

# numResponses: 6
# numEntries: 5

log message:

2023-11-16T18:37:26.923734457+00:00  WARN     │  ┕━ 🚧 [warn]: Ignoring unrecognized group attribute: uidnumber\n\
<!-- gh-comment-id:1814977853 --> @vincentDcmps commented on GitHub (Nov 16, 2023): yes see answer of graphql query ```GraphQl { "data": { "user": { "id": "admin", "attributes": [ { "name": "uidNumber", "value": [ "10000" ] } ], "groups": [ { "id": 1 }, { "id": 4 } ] } } } ``` and with this ``` ldapsearch -H ldap://192.168.1.42:3890 -D uid=admin,ou=people,dc=ducamps,dc=eu -w 'REPLACE_WITH_PASSWORD' uidNumber ``` ``` # extended LDIF # # LDAPv3 # base <dc=ducamps,dc=eu> (default) with scope subtree # filter: (objectclass=*) # requesting: uidNumber # # admin, people, ducamps.eu dn: uid=admin,ou=people,dc=ducamps,dc=eu # lldap_admin, groups, ducamps.eu dn: cn=lldap_admin,ou=groups,dc=ducamps,dc=eu # lldap_password_manager, groups, ducamps.eu dn: cn=lldap_password_manager,ou=groups,dc=ducamps,dc=eu # lldap_strict_readonly, groups, ducamps.eu dn: cn=lldap_strict_readonly,ou=groups,dc=ducamps,dc=eu # toto, groups, ducamps.eu dn: cn=toto,ou=groups,dc=ducamps,dc=eu # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQUEAA== pagedresults: estimate=5 cookie= # numResponses: 6 # numEntries: 5 ``` log message: ``` 2023-11-16T18:37:26.923734457+00:00 WARN │ ┕━ 🚧 [warn]: Ignoring unrecognized group attribute: uidnumber\n\ ```
Author
Owner

@nitnelave commented on GitHub (Nov 16, 2023):

Oh, I think I know what's going on: we create the attribute with the exact name, keeping the case, but we try to find it in a case insensitive way by converting the input to lowercase. If you delete your attribute and recreate it as "uidnumber" (no uppercase), does it work? If so, I already have a WIP PR that'll fix this.

<!-- gh-comment-id:1815352421 --> @nitnelave commented on GitHub (Nov 16, 2023): Oh, I think I know what's going on: we create the attribute with the exact name, keeping the case, but we try to find it in a case insensitive way by converting the input to lowercase. If you delete your attribute and recreate it as "uidnumber" (no uppercase), does it work? If so, I already have a WIP PR that'll fix this.
Author
Owner

@vincentDcmps commented on GitHub (Nov 17, 2023):

indeed this works with attribute in lowercase thanks

<!-- gh-comment-id:1816871596 --> @vincentDcmps commented on GitHub (Nov 17, 2023): indeed this works with attribute in lowercase thanks
Author
Owner

@nitnelave commented on GitHub (Dec 28, 2023):

We now have an (experimental) CLI frontend for the custom attributes: https://github.com/Zepmann/lldap-cli
Thanks @Zepmann !

Feel free to try it out, it should greatly simplify handling of attributes (but it's not user friendly, only admin friendly)

<!-- gh-comment-id:1871270300 --> @nitnelave commented on GitHub (Dec 28, 2023): We now have an (experimental) CLI frontend for the custom attributes: https://github.com/Zepmann/lldap-cli Thanks @Zepmann ! Feel free to try it out, it should greatly simplify handling of attributes (but it's not user friendly, only admin friendly)
Author
Owner

@Zepmann commented on GitHub (Dec 28, 2023):

Feel free to try it out, it should greatly simplify handling of attributes (but it's not user friendly, only admin friendly)

I prefer the term user-centric. 😉

If there are any questions about the usage of LLDAP-CLI, please let me know by tagging me in. To get you started, consider these commands:

$ lldap-cli -D admin -w somepassword schema attribute user list
$ lldap-cli -D admin -w somepassword user attribute list someuser
$ lldap-cli -D admin -w somepassword user attribute values someuser mail

$ lldap-cli -D admin -w somepassword schema attribute user add mailAlias string -l -v -e
$ lldap-cli -D admin -w somepassword user update add someuser mailAlias someuser1@example.com
$ lldap-cli -D admin -w somepassword user update add someuser mailAlias someuser2@example.com
$ lldap-cli -D admin -w somepassword user attribute values someuser mailAlias

Replace admin and somepassword with valid LLDAP credentials of an administrator account.

The first set of command shows you which user attributes are in the schema, which user attributes have a value for user someuser, and what the value of the mail attribute is for someuser.

The last set of command defines new user attribute mailAlias in the schema, gives it two values for user someuser (since it is a list, it can have multiple values), and shows the values as configured.

<!-- gh-comment-id:1871326763 --> @Zepmann commented on GitHub (Dec 28, 2023): > Feel free to try it out, it should greatly simplify handling of attributes (but it's not user friendly, only admin friendly) I prefer the term [user-centric](https://wiki.archlinux.org/title/Arch_Linux#User_centrality). :wink: If there are any questions about the usage of LLDAP-CLI, please let me know by tagging me in. To get you started, consider these commands: ``` $ lldap-cli -D admin -w somepassword schema attribute user list $ lldap-cli -D admin -w somepassword user attribute list someuser $ lldap-cli -D admin -w somepassword user attribute values someuser mail $ lldap-cli -D admin -w somepassword schema attribute user add mailAlias string -l -v -e $ lldap-cli -D admin -w somepassword user update add someuser mailAlias someuser1@example.com $ lldap-cli -D admin -w somepassword user update add someuser mailAlias someuser2@example.com $ lldap-cli -D admin -w somepassword user attribute values someuser mailAlias ``` Replace `admin` and `somepassword` with valid LLDAP credentials of an administrator account. The first set of command shows you which user attributes are in the schema, which user attributes have a value for user `someuser`, and what the value of the `mail` attribute is for `someuser`. The last set of command defines new user attribute `mailAlias` in the schema, gives it two values for user `someuser` (since it is a list, it can have multiple values), and shows the values as configured.
Author
Owner

@jakob42 commented on GitHub (Jan 6, 2024):

I'm a bit unclear about whats already in the current 0.5 release. I thought custom attributes would be already included, but it doesn't seem to work for me with the commands Zepmann had here as an example:

$ lldap-cli schema attribute user add mailalias string -l -v -e
ERROR: Unknown type \AttributeType\
Unknown field \addUserAttribute\ on type \Mutation\

Do I need a dev version to test this feature?

<!-- gh-comment-id:1879637919 --> @jakob42 commented on GitHub (Jan 6, 2024): I'm a bit unclear about whats already in the current 0.5 release. I thought custom attributes would be already included, but it doesn't seem to work for me with the commands Zepmann had here as an example: ``` $ lldap-cli schema attribute user add mailalias string -l -v -e ERROR: Unknown type \AttributeType\ Unknown field \addUserAttribute\ on type \Mutation\ ``` Do I need a dev version to test this feature?
Author
Owner

@Zepmann commented on GitHub (Jan 6, 2024):

@jakob42

Custom attributes only work in the current development version. There hasn't yet been a stable release of LLDAP that includes it.

<!-- gh-comment-id:1879659688 --> @Zepmann commented on GitHub (Jan 6, 2024): @jakob42 Custom attributes only work in the current development version. There hasn't yet been a stable release of LLDAP that includes it.
Author
Owner

@nitnelave commented on GitHub (Jan 6, 2024):

I was waiting until we have a UI for it before releasing it. Now that we have the CLI tool, it's not the best but I'll make a stable release. It has been already tested by several people, and no major issues remain. I'll still want to fix #763 before releasing though.

<!-- gh-comment-id:1879663745 --> @nitnelave commented on GitHub (Jan 6, 2024): I was waiting until we have a UI for it before releasing it. Now that we have the CLI tool, it's not the best but I'll make a stable release. It has been already tested by several people, and no major issues remain. I'll still want to fix #763 before releasing though.
Author
Owner

@Zepmann commented on GitHub (Jan 6, 2024):

@nitnelave

You can always make a stable release in which you label some features experimental, such as custom attributes. This will temper expectations, especially since this new feature is only usable with community-contributed tooling for now and has not been extensively tested.

<!-- gh-comment-id:1879669112 --> @Zepmann commented on GitHub (Jan 6, 2024): @nitnelave You can always make a stable release in which you label some features experimental, such as custom attributes. This will temper expectations, especially since this new feature is only usable with community-contributed tooling for now and has not been extensively tested.
Author
Owner

@jakob42 commented on GitHub (Jan 6, 2024):

Thanks @nitnelave! No need to hurry on my account, I'll either patiently wait or get a dev version. :-)

<!-- gh-comment-id:1879671498 --> @jakob42 commented on GitHub (Jan 6, 2024): Thanks @nitnelave! No need to hurry on my account, I'll either patiently wait or get a dev version. :-)
Author
Owner

@nitnelave commented on GitHub (Oct 21, 2024):

The frontend is now complete for custom attributes (no aliases, yet), feel free to try it and report any issues.

<!-- gh-comment-id:2427924430 --> @nitnelave commented on GitHub (Oct 21, 2024): The frontend is now complete for custom attributes (no aliases, yet), feel free to try it and report any issues.
Author
Owner

@twitzelbos commented on GitHub (Jun 10, 2025):

I'm interested in this as well. Are there any other people interested in using lldap for posix id provider applications?

<!-- gh-comment-id:2960428697 --> @twitzelbos commented on GitHub (Jun 10, 2025): I'm interested in this as well. Are there any other people interested in using lldap for posix id provider applications?
Author
Owner

@nitnelave commented on GitHub (Jun 10, 2025):

using lldap for posix id provider applications?

Have you checked out our PAM/SSSD configuration guides?

<!-- gh-comment-id:2960457057 --> @nitnelave commented on GitHub (Jun 10, 2025): > using lldap for posix id provider applications? Have you checked out our PAM/SSSD configuration guides?
Author
Owner

@twitzelbos commented on GitHub (Jun 10, 2025):

using lldap for posix id provider applications?

Have you checked out our PAM/SSSD configuration guides?

I guess not. Thank you for pointing it out.

<!-- gh-comment-id:2960675363 --> @twitzelbos commented on GitHub (Jun 10, 2025): > > using lldap for posix id provider applications? > > Have you checked out our PAM/SSSD configuration guides? I guess not. Thank you for pointing it out.
Author
Owner

@twitzelbos commented on GitHub (Jun 11, 2025):

@nitnelave are there any premade scripts to affect all the attribute schema changes for SSSD/posix?

<!-- gh-comment-id:2963459604 --> @twitzelbos commented on GitHub (Jun 11, 2025): @nitnelave are there any premade scripts to affect all the attribute schema changes for SSSD/posix?
Author
Owner

@nitnelave commented on GitHub (Jun 11, 2025):

@nitnelave are there any premade scripts to affect all the attribute schema changes for SSSD/posix?

Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need.

<!-- gh-comment-id:2963656158 --> @nitnelave commented on GitHub (Jun 11, 2025): > @nitnelave are there any premade scripts to affect all the attribute schema changes for SSSD/posix? Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need.
Author
Owner

@twitzelbos commented on GitHub (Jun 11, 2025):

@nitnelave are there any premade scripts to affect all the attribute schema changes for SSSD/posix?

Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need.

Let me know if you need any help, I have a little bandwidth.

So today I should just use lldap-cli ?

<!-- gh-comment-id:2964053918 --> @twitzelbos commented on GitHub (Jun 11, 2025): > > [@nitnelave](https://github.com/nitnelave) are there any premade scripts to affect all the attribute schema changes for SSSD/posix? > > Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need. Let me know if you need any help, I have a little bandwidth. So today I should just use lldap-cli ?
Author
Owner

@nitnelave commented on GitHub (Jun 11, 2025):

Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need.

Let me know if you need any help, I have a little bandwidth.

So today I should just use lldap-cli ?

You can use lldap-cli or the web frontend. The plugin issue is #714, but right now we have a contributor who has done most of the work in not-yet-PR'd private branches, so I don't think there's much you can do. But once we get something going, feel free to follow the issue, we might call for early adopters to provide feedback/develop plugins.

<!-- gh-comment-id:2964210433 --> @nitnelave commented on GitHub (Jun 11, 2025): > > Not yet, but we're working on a plugin API which will include not only the setup, but also updating users on creation and almost everything else you might need. > > Let me know if you need any help, I have a little bandwidth. > > So today I should just use lldap-cli ? You can use lldap-cli or the web frontend. The plugin issue is #714, but right now we have a contributor who has done most of the work in not-yet-PR'd private branches, so I don't think there's much you can do. But once we get something going, feel free to follow the issue, we might call for early adopters to provide feedback/develop plugins.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#31
No description provided.