Skip to content
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

RH6 support #14

Closed
brettswift opened this issue Nov 7, 2016 · 5 comments
Closed

RH6 support #14

brettswift opened this issue Nov 7, 2016 · 5 comments

Comments

@brettswift
Copy link

The first thing I noticed was the service restarts in the domain-join command.

A question around that command however - why don't you run it in the module?

Do you do pam.d authorization somewhere to allow certain groups / users to log into the machine?

Also the password is baked into the domain-join command / script - which is a user that can add machines to the domain. The account should have access only to a single OU in Active Directory so I guess risk is low, but ultimately it should require elevated privileges to run this I would expect.

I'd be willing to make a couple of these changes and split this multi-request card out into a couple more, but maybe you have some feedback on these comments first. If I understand how you run the domain-join and add AD groups / users - leveraging this module might be more clear.

Thanks Rob!
@bswift on the puppet slack if you feel like pinging me instead.

@rnelson0
Copy link
Owner

rnelson0 commented Nov 7, 2016

Workflow:

  • Create a template (EL7 typically)
  • Provision new VMs from the template
  • Run puppet on the new VMs
  • Join VMs to the domain through manual run of /usr/local/bin/domain_join when applicable (we typically disable non-root login and do not use local users, but those are controllable through hiera).

Reasons joining the domain is a separate step: 1) the module doesn't support joining on first-run currently (seriously, it's another yak to shave), 2) domain joins are "expensive" to undo relative to the cost of doing them, so we skip this until we're sure the VM will persist, 3) sometimes it fails in unexpected ways (specific to our environment), 4) we have a low volume of new domain-joined VMs which, in conjuction with 3, encourages manual runs for verification.

We use the unix group attributes in AD OUs to restrict access there, rather than through PAM configuration.

I would definitely be willing to entertain general workflow improvements here!

@brettswift
Copy link
Author

brettswift commented Nov 8, 2016

Thanks for the clarification.

We do a lot of provisioning on demand and are trying to speed up our delivery. I was trying to use the ajjahn/puppet-samba module but it does the net ads join after the kinit which I'm clueless as to how that will work. However he does have a decent idempotency check I might model and simplify if possible. Haven't had a response to that module yet.

AD join script:
https://github.com/ajjahn/puppet-samba/tree/master/templates

Question 1: re: 2) Is it expensive to leave the domain because that step is manual in an LDAP tree? I thought net ads leave was good enough? Maybe I'm missing a reason it might be expensive for us too...

A manual change of the domain-join to init.d/sshd restart is all that seems to be required for RH6.

As for the domain join script, a --join or --leave command could help this be driven from hiera, and that could be an exec driven by hiera.

As for the domain-join - we have local users right now but the idea is to remove all local users except for those service accounts. That still leaves some local vendor accounts (with poor privilege restrictions). I'm probably ok leaving that script there for now. However:

Question 2: Would it affect you if it was in /usr/local/sbin with root ownership and 700 level access so just root / sudo could run it or view it? (as it has a password in the file)

I'd love to control users via hiera still, or at least assign groups. I haven't used PAM before but sounds like that's what I'd want.. maybe another module has that built in already.

@brettswift
Copy link
Author

Another change I might have to make is to make the net ads dns register command optional. Our DNS fails to configure here, and I'm not certain but I'm thinking that option puts dyndns_update = true in the sssd.conf file. :(

Maybe I need too many changes here that might not be what you want.. feel free to say so if you think that's the case! I've just found the modules that use winbind etc don't work for me so am trying different modules :)

@rnelson0
Copy link
Owner

rnelson0 commented Nov 8, 2016

I'm okay with all your proposed changes. I think a few flags like manage_dns would be enough to make it flexible enough for a majority of use cases, and we could even offer parameters for the template locations if someone wanted to totally override it.

@brettswift
Copy link
Author

closing as it's merged in, however we found a bug with the code after the rebase.. I'll open a new ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants