https://www.puppet.com/community logo
Join Slack
Powered by
This message was deleted.
# puppet-enterprise
s
This message was deleted.
s
If you haven’t already, there’s a couple of lines at the bottom of 
/etc/puppetlabs/console-services/logback.xml
that when uncommented (and console-services restarted) will provide a lot more detail in the logs:
that’s the first thing I would do
t
Which specific log should I be looking at after making that change? The console-services log?
s
yep, tail the console-services.log and exercise the login
t
@steveax, so I tried your suggestion and in the debug logs, it mentions unexpected attributes and it provides the respective oids. Not sure what next I need to do to get the group piece working.
s
what’s the identity provider?
t
I believe its Shibboleth
s
hmmm, not familiar with that one
still kinda gobsmacked how fiddly setting these up is
t
Yeah, so the user is created but not being added to the desired group and user role.
The documentation isn't clear either
s
ours, or Shibboleth?
t
The puppet documentation
Its not clear how the group bindings needs to be setup for connecting to Idp
s
yeah, we have pretty complete docs for Okta and MS, but there are so many variations
what do you have for the group binding?
t
I have the OID for the IsMemberOf
Puppet didn't like the friendly names so I had to use the OIDs
s
can you get the logging from the IP end?
t
A separate team manages that so unfortunately, I don't have access to those logs.
I have reached out to them so hopefully, they will check and find something to act on.
I appreciate your assistance with this.
s
yeah, wish I had something more concrete to offer you 😞 feel free to ping me next week!
Jon is out today but is back next week and might have some insight as well
t
Sounds good. I will ping you next week.
s
👍
t
@steveax, hope you had a good weekend. Just wanted to follow-up on our conversation from last week.
s
\o I did in fact have a good weekend - hope yours was good too!
did you manage to get logs from the IP side?
j
There are several things that need to happen to get users to login to PE. Sounds like you have gotten the basic handshake working, but the assertions are either missing group attributes, or they are bound to the wrong attributes in PE.
Once you have the logging turned up, you might see messages about 
Unexpected attribute
our logging will also list the groups the users are bound to. Also you will need to make the 'user group' in PE with the same attribute value as comes from the IdP (as the "login") and then assign roles to that group.
What you have are users with no roles, and thus no permission to use the console.
t
@steveax, no logs yet, from the Idp side. @jonathan.newman, when I turned up the logging, I did see Unexpected attribute messages but I didn't see any list of groups. The Unexpected attribute messages showed OIDs and not friendly names. I did create the "user group" in PE. Same name as the group created on the Idp end and then assigned the appropriate role to that group.
I am not sure else needs to happen for things to work.
j
The OIDs may be correct.
It all depends on what is provided by the IdP.
And if the OIDs are the actual groups in the IdP, then you want to make the login for those groups the same value.
Once the attribute key matches a bound key in Puppet Enterprise, the "Unexpected attribute" messages should go away as it will expect the attribute. For example in the Microsoft products the keys are:
The "groups binding" is likely the one that needs to be updated, if the groups are under a different key than you are using.
Unless the OIDs are the keys, which is more likely what you meant.
t
Hmm, what do you mean by keys?
Do you mean like name, emailaddress, displayname and groups? Is that what you are calling as keys?
j
yes. The attributes are key/value pairs in the assertion.
Open in Slack
PreviousNext
Powered by