New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Arbitrary and Duplicate Text Fields #67
Comments
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. |
Here's an RFC for this feature: https://docs.google.com/document/d/1BdizgwX6Pvy5hqH8_HzSg3LCa66tQSDhrTsdhF80ySY/edit?usp=drivesdk |
Wow! I was searching for ldap-ui when I stumbled upon this project, which seems pretty awesome. OTOH, reading the RFC, what use does 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 |
@Samonitari The 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, |
Fair enough. I am still wrapping my head around a few things to solve differently (or at all) with LLDAP. |
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 😜 |
Feel free to join the Discord :) |
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. |
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
<#67 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGCPWNRYACKZ5UVC6MPBHTW7WQK3ANCNFSM5GPAAAZA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Is there a timeline for this feature? LLDAP is a truly wonderful project, many thanks for all the team's efforts. Again, many thanks for the fantastic project and all the effort, very much appreciated. :) |
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 This issue requires a fundamental schema and query change, and I don't want to break everything. |
@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 :) |
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 ;) |
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... |
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? |
@vincentDcmps can you try specifically requesting the attribute by name in the LDAP query? |
yes see answer of graphql query {
"data": {
"user": {
"id": "admin",
"attributes": [
{
"name": "uidNumber",
"value": [
"10000"
]
}
],
"groups": [
{
"id": 1
},
{
"id": 4
}
]
}
}
} and with this
log message:
|
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. |
indeed this works with attribute in lowercase thanks |
We now have an (experimental) CLI frontend for the custom attributes: https://github.com/Zepmann/lldap-cli 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:
Replace The first set of command shows you which user attributes are in the schema, which user attributes have a value for user The last set of command defines new user attribute |
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:
Do I need a dev version to test this feature? |
Custom attributes only work in the current development version. There hasn't yet been a stable release of LLDAP that includes it. |
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. |
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. |
Thanks @nitnelave! No need to hurry on my account, I'll either patiently wait or get a dev version. :-) |
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:
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: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:
Task breakdown:
The text was updated successfully, but these errors were encountered: