Group principal?

[Bnicke]

Is it possible to add a group somehow?
I tried auth_gss_authorized_principal <group>@<realm> (in several different formats), it gives me an 403, auth_gss_authorized_principal <username>@<realm> works.

[tbmorris]

Agreed. The ability to control access by a single authorized group will be vastly superior to calling out each user that is authorized to access a location.

[xobot42]

Hi. Are there any news about this issue?
Will it be released? Or may be have a some trick, how do it?

[stnoonan]

No trick. To be honest, I don't even have a testbed setup for this project at this point. I'll take pull requests, but the one that would be most valuable would be adding tests :-(.

[crpb]

Hi there,

does anyone have a working example of auth_gss_authorized_principal_regex from 467b2a3 for all Users in a certain Group?

I only found this comment which never was answered.

[hawicz]

Kerberos principals have no concept of groups at all, it's really not sensible to ask about how to make auth_gss_authorized_principal_regex match a group. It's the same as asking what regex would you write to check whether "John Smith" is in a group - you can't write such a regex.
The use of the phrase <group> in the README.md is rather misleading, and should really say something like <instance> instead (to match the definition of the parts of a principal, as per https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html)

At most you could write a regex that matches multiple different principals, i.e. ^(usera|userb|userc)@realm

[Alphix]

Kerberos principals have no concept of groups at all

Indeed, this is out-of-scope of this module, you'd need to add principal-to-group-mapping (e.g. via LDAP) to your underlying application instead.

I've updated the README.md to remove references to "groups"