[Please honor Reply-To: smf-discuss at opensolaris.org]
Background: We have a need for common storage of various configuration
properties relating to Active Directory domains (but not
necessarily only AD domains). System components that need
to access this include:
- the CIFS server
- the ID mapping service (svc:/system/idmap)
- nss_ad (AD name service backend for name service switch)
- possibly the CIFS client
- possibly other components in the future (imagine if we
had something like ADSI -AD scripting interface- for
Solaris)
Configuration properties mostly include items that can be,
and normally would be auto-discovered but which the sysadmin
might want to override. E.g., a list of preferred domain
controllers.
One possibility that occurred to me:
svc:/domain/<domain-type>/<leftmost-label>/../<rightmost-label>:default
For example, properties for the AD domain 'foo.bar.example' would be
stored in 'svc:/domain/ad/foo/bar/example:default'.
Problems:
1) Wouldn't it be nice to be able to use actual domain names instead of
having to replace '.' with '/'?
I.e., 'svc:/domain/ad/foo.bar.example:default' reads a lot better
than 'svc:/domain/ad/foo/bar/example:default'.
2) What about internationalized domain names?
Should IDN labels be used in ACE (punycoded, ASCII) form? If stored
in Unicode form (probably UTF-8) how would we deal with such FMRIs in
non-UTF-8 locales?
Yes, this question answers itself: use ACE encoding.
I don't know what the story is with AD and IDN today, but it used to
be that early versions of AD allowed the use of internationalized
domain names well outside the IDN framework. This might complicate
things if we want to support such AD domains. But then, I'd think
the burden is on Microsoft to deal with making such legacy AD domains
interoperate in a world where IDN has been deployed.
3) Consider http://blogs.sun.com/nico/entry/can_we_map_ids_between
We may someday want to assign locally-generated SID prefixes to
non-AD domains. Such SID prefixes would have to be unique. How can
we make SMF enforce this? And if we can't, can we live with that?
If we store them in the domain's svc FMRI then we can't enforce
uniqueness. Even if we store them in svc:/domain/<domain-type> in a
multi-valued property we still lack a way to enforce uniqueness.
And yet I don't want to invent a non-SMF method for storing all this
stuff.
Comments? Advice?
I half-expect revulsion.
Nico
--
