search

dayglojesus / managedmac

Comprehensive Puppet module for OS X.
http://dayglojesus.github.io/managedmac/
Apache License 2.0
62 stars 21 forks source link

dsconfigad not setting -prefered param #85

Closed groob closed 9 years ago

groob commented 9 years ago 
2015-07-13 12:53:30.883 dscl[7208:81664] -[__NSCFNumber length]: unrecognized selector sent to instance 0xffffffc00000ff37
*** Uncaught Exception: <NSInvalidArgumentException> (-[__NSCFNumber length]: unrecognized selector sent to instance 0xffffffc00000ff37)
2015-07-13 12:53:31.483 dscl[7220:81711] -[__NSCFNumber length]: unrecognized selector sent to instance 0xffffffc00000ff37
*** Uncaught Exception: <NSInvalidArgumentException> (-[__NSCFNumber length]: unrecognized selector sent to instance 0xffffffc00000ff37)
Notice: /Stage[main]/Managedmac::Activedirectory/Dsconfigad[ad1]/ensure: created
Notice: Dsconfigad[ad1](provider=default): Binding to domain...
Error: /Stage[main]/Managedmac::Activedirectory/Dsconfigad[ad1]: Could not evaluate: Execution of '/usr/sbin/dsconfigad -add ad1 -computer osx-10_10 -username Administrator -password secret -ou CN=Computers,DC=whitbyschool,DC=net -force' returned 70: dsconfigad: Authentication server could not be contacted. (5200)

managedmac::activedirectory::provider: dsconfigad managedmac::activedirectory::hostname: ad1 managedmac::activedirectory::preferred_dc_server: ad1.whitbyschool.net

dayglojesus commented 9 years ago

@groob if you remove the param, it succeeds?

groob commented 9 years ago

I was able to get it working by setting hostname to dc and removing the preferred_dc_server.

managedmac::activedirectory::hostname: whitbyschool.net

The preferred_dc_server does not appear to be listed in the params though, and I always get the 'NSInvalidArgumentException's above, even if puppet does not show any errors.

dayglojesus commented 9 years ago

The NSInvalidArgumentException might be a bit of a "red herring"...

I see from the log that this error is produced by a call to dscl, but the Dsconfigad type/provider never shells out to dscl. I have to assume it's another process or maybe dsconfigad itself!

Still, I do notice that the bind operation is not building -preferred into the args list! Weird.

Looks like a bug to me...

dayglojesus commented 9 years ago

Okay, after looking at the code, I think understand what's happening, but it may be a little difficult to explain...

Background

There are are few things to understand:

  1. As per the dsconfigad man page, the -preferred flag can be provided both during and after the bind operation (-add)
  2. Dsconfigad (the provider) breaks the bind operation into two discrete operations:
    • bind: bind the client to the domain as specified
    • configure: configure the plugin options (mount style, groups, etc.)
  3. Dsconfigad sets -preferred during the configure portion of the operation, NOT the bind op

You can see the basic operation here:

https://github.com/dayglojesus/managedmac/blob/master/lib/puppet/provider/dsconfigad/default.rb#L267-L268

IME: performing a bind in this manner, usually results in a more reliable methodology. I've found that throwing too many CLI options at dsconfigad simultaneously can be confusing and will fail more often.

However, the decision to push -preferred into the plugin configuration rather than the bind was mainly an economical one -- code-wise, it's just easier to accommodate.

The Issue is not a Bug

That said, I don't think the issue you have reported has anything to do with where or when the -preferred flag is invoked, BUT I cannot prove that -- not in my environment anyway.

I think the failure you are seeing occurs because the domain you are specifying, is unqualified.

managedmac::activedirectory::hostname: ad1 is not a fully qualified Active Directory domain, it's just the short hostname of one of the DCs.

That may not be adequate information to supply to dsconfigad if your host's DNS configuration can't resolve it.

For example, if you had no domain search suffixes configured in your client's network configuration, asking your DNS servers for ad1 may be insufficient.

networksetup -getsearchdomains Ethernet

If that returns nothing, chances are you won't be able to resolve the short hostname manually using this command:

host ad1

If that command works, then I may be wrong.

However, proof of this idea may actually be in your 'workaround' wherein you supplied a resolvable domain ...

managedmac::activedirectory::hostname: whitbyschool.net

... and the bind operation succeeded.

If you execute the following cmd, will your machine bind?

/usr/sbin/dsconfigad -add whitbyschool.net -computer osx-10_10 -username Administrator -password secret -ou CN=Computers,DC=whitbyschool,DC=net -force

Final Thought

I wonder if all this isn't simply some confusion regarding the managedmac::activedirectory::hostname parameter itself.

This param label hostname is a poor choice. It is, however the one that Apple uses and therefore selected so as to conform to their documentation.

In Apple's documentation... hostname != computername Instead, hostname == your.ad.domain

Which is COMPLETELY NON-INTUITIVE.

I hope all this makes sense.

Please let me know! Cheers.

groob commented 9 years ago

I was able to get this to work by correctly setting managedmac::activedirectory::hostname

thank you for the detailed explanation.