The attribute `o` is already included in the `gluuPerson` objectclass. You may need to enable this attribute in the Configuration/Attributes section of oxAuth. Once enabled, I would think you could release this attribute via SAML. If you're using OpenID Connect, you'd need to add this user claim (attribute) to a scope, and then release the scope. Let us know if you have the `o` attribute enabled, and if that clears up the problem.

Hi, Nemeesh. Agree with Michael, but you shoudn't use `o` as attribute you'll be changing, as it's being used internally by Gluu itself. It also seems to me your over-estimate significance of Gluu's internal LDAP tree's structure, like which entries are stored under what ou - you shouldn't think about in from that perspective. All user entries in Gluu are placed beneath "ou=people" node, and it's you who is responsible to mark them in such way you can break them into some categories in the future. It's not that easy to change this behaviour (mb it's impossible) So if you need to be able to distinguish users from different organizations, you must choose some attribute (mb to create one) and either use mapping table, or CR script to store name of organization at the moment each user is imported to Gluu by CR. **eduPersonOrgDN** may be a good choice, if the string you'll be storing in it formatted as Distinguished Name. Otherwise, it would be better to choose some other attribute/name, like to simply create a custom attribute **OrgName** - to prevent any confusion in the future. Then you can just release this attribute like any other of them. Best regards, Alex.

It seems metadata is indeed is there, but description is somewhat strange: > Organization i-number o gluuPerson Organization i-number "Organization i-number". Not sure what that means. Is it a good idea to use it as organization name?

It's true we use the o attribute for the organization inum i.e. `inum=(person-inum),ou=people,o=(org-inum),o=gluu` but this is not populated for the person entry anyway, so I would think releasing it would be ok. I'd like to see the ldif for the person entry. Is the `o` attribute there for a given person?

Nemeesh, it's ok to use `o` the way you want. Let's start with brief troubleshooting. Could you check for now: 1. In `o` attribute's properties - is it active? 2. In your mappings or CR script: is some value is assigned to `o`? Please also do direct directory search within Gluu's directory, with `ldapsearch` or from web UI, for a user entry you use to test your setup and make sure its `o` attribute has some value. 3. If you use SAML to release it: is it added to the Trust Relationship you are testing? 4. If you use OIDC: check the attribute's properties again, make sure that "Usage Type" is set to "OpenID", and some claim name is set for it in "oxAuth claim name". Then check that it's added to some scope on the "OpenID Connect -> Scopes" page (when adding it you'll use the "oxAuth claim name" you set for it before). Then on the "OpenID Connect -> Clients" you'll need to make sure the scope you included it in is allowed to be released to client your RP uses.

Hi, Neemesh. Any updates on the issue? Have you tried to follow steps I provided?

Hello all, thanks for all the responses, apologies for the lack of a response from myself until now, I was out of the office yesterday. From Michael (17 Oct 2016 at 8:24 p.m. BST): > Let us know if you have the o attribute enabled, and if that clears up the problem. "o" is active. The description says "Organization i-number" so I thought this may not be the best field to use as I thought it's intention was only to be an id number of some kind representing the organisation rather than the name itself. From Michael (17 Oct 2016 at 9:23 p.m. BST): > I'd like to see the ldif for the person entry. Is the o attribute there for a given person? I'm afraid I'm not sure how to export the person entry ldif, if you can send me some instructions I can certainly follow them and upload the data you need to see. I'm not sure if this helps at all, but if I look under "users">"manage people">[Select a user] I can't see "o" or organization listed here under each person (I can see it on the left "Add attributes to person entry" under the "organization i-num" label). [http://pasteboard.co/1G0U1VAn6.png](http://pasteboard.co/1G0U1VAn6.png) From Aliaksandr (17 Oct 2016 at 9:23 p.m. BST): > 1. In o attribute's properties - is it active? > 1. In your mappings or CR script: is some value is assigned to o? Please also do direct directory search within Gluu's directory, with ldapsearch or from web UI, for a user entry you use to test your setup and make sure its o attribute has some value. > 1. If you use SAML to release it: is it added to the Trust Relationship you are testing? > 1. If you use OIDC: check the attribute's properties again, make sure that "Usage Type" is set to "OpenID", and some claim name is set for it in "oxAuth claim name". Then check that it's added to some scope on the "OpenID Connect -> Scopes" page (when adding it you'll use the "oxAuth claim name" you set for it before). Then on the "OpenID Connect -> Clients" you'll need to make sure the scope you included it in is allowed to be released to client your RP uses. 1. The "o" attribute is active 1. In the CR mappings, I did have "o" mapped to a custom field storing the organization name I have in the user directory (which worked), but I then removed this as the description of o in Gluu was "Organization i-number" and didn't quite sound like the right thing to use. Could you confirm if this attribute is something fairly standard to store organisation names into (afraid I'm relatively new to the LDAP world, so I want to keep things standard where I can)? 1. We use SAML, but only for one trust relationship that doesn't require this attribute 1. I checked the attribute properties, and the usage type was "Not defined" and the oxAuth claim name was "o". Is "o" safe to store the organization name itself (rather than an i-number as the description infers, see the question in point 2)? If so, I'll then try to make the changes there, if not, I can use Aliaksandr'a suggestion of a custom attribute (i.e. OrgName). I just need a bit of a steer on the attribute to use for organisation so we're not digressing too much from standard ldap practices. Thanks for all your responses (and being patient with me!)

> I'm not sure if this helps at all, but if I look under "users">"manage people">[Select a user] I can't see "o" or organization listed here under each person (I can see it on the left "Add attributes to person entry" under the "organization i-num" label). >http://pasteboard.co/1G0U1VAn6.png On your screenshot I don't see that user in question has some value assigned to this attribute. Otherwise it would be present at the pane to the right, in the list of its attributes. I believe by LDIF Michael meant output of `ldapsearch` tool for a person you use in your tests. Like, if this user doesn't have value assigned to `o` attribute, then it can be expected nothing is released to SP, right? :) Here is an example of ldap search you could run from within container (you also could try `jxplorer` tool if you prefer GUI more): `# /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager' -w 'YOUR_LDAP_PASS' -b 'o=gluu' -z 10 '(uid=UID_OF_USER_IN_QUESTION)'` Please also note that if you set mapping for `o` attribute not at the same moment you first started CR, but later, after some pulls already have happened, most likely those mapping hasn't yet been applied even once. That's how CR is implemented atm. Please try to stop CR and completely empty snapshot directory (check CR page for the full path to it), then start CR again. This will force update to all entries and new mappings will be applied too. >Could you confirm if this attribute is something fairly standard to store organisation names into (afraid I'm relatively new to the LDAP world, so I want to keep things standard where I can) Yes, it is. It was wrong description in web UI, will be fixed in next release >Could you confirm if this attribute is something fairly standard to store organisation names into (afraid I'm relatively new to the LDAP world, so I want to keep things standard where I can) Let's proceed with `o` attribute for now, there shouldn't be any problems with using it, no need to create another one.