-----Original Message-----
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Vinícius Ferrão
Sent: 26. maj 2014 00:57
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] Login with Enterprise Principal Name with AD backend
On May 25, 2014, at 19:51, steve <steve(a)steve-ss.com> wrote:
On Sun, 2014-05-25 at 22:31 +0000, Vinícius Ferrão wrote:
> Hello guys,
>
> I’m running sssd version 1.11 in Ubuntu 14.04 LTS (1.11.5-1ubuntu3) to authenticate
users from Active Directory from WIndows Server 2012 R2, and I’m trying to achieve logins
with the User Principal Name for all users of the domain. But the UPN are always
Enterprise Principal Names.
>
> Let-me illustrate the problem with my user account:
>
> Domain:
local.example.com
> sAMAccountName: ferrao
> UPN: ferrao(a)example.com (there’s no local in the UPN)
>
> I can successfully login with the sAMAccount atribute, which is fine, but I can’t
login with ferrao(a)example.com which is my UPN. The optimum solution for me is to allow
logins from sAMAccount and the UPN. If’s not possible, the UPN should be the right way
instead of the sAMAccountName.
>
> Another annoyance is the homedir pattern with those options in sssd.conf:
> default_shell = /bin/bash
> fallback_homedir = /home/%d/%u
>
> What I would like to achieve is separated home directories from the EPN. For
example:
>
> /home/example.com/user
> /home/whatever.example.com/user
>
> But with this pattern I can’t map the way I would like to do.
>
> I’ve looked through man pages and was unable to find any answers for this issues.
>
> Thanks in advance,
> Vinícius.
Hi
Not sure about the accountname bit but the 2012 schema has full
support for rfc2307 out of the box. Store whatever home directory you
like on a per user basis under their DN as:
uinixHomeDirectory
Likewise:
loginShell
with whatever shell they need.
The 1.11.5 ad backend will automatically grab them with no further
configuration needed.
Steve
Hello Steve, thank you for the fast reply. I was aware of the AD ldap schema.
I’m avoiding to mess with Unix specific atributes inside AD because Microsoft started the
decommissioning of Unix Services. Today still exists hacks to enable the UNIX Attributes
tab in the User Preferences, but they can only be enabled activating Services for NIS from
the Powershell.
I know it’s an option, but the whole point of using SSSD is to avoid messing with AD. If
it’s impossible to achieve in the SSSD side, that will be the solution for the second
issue.
Thank you,
Vinícius.
Hi there,
So what is the scenario for minimal possible AD mess - do not use at all Posix
Attributes?
If we don't plan to use Nis services, but need Posix schema and Posix attributes for
searching uid/gid /autofs maps- are we not safe?
It is important decision for our project, as we are just about to ask for "messing
AD" by attaching gid number for existing AD groups and keep gid number assigning for
all groups created in the future.
It seems to be the rightest way to achieve unique uid/gid on the Linux clients, as we
have different kind of storage (Sun storage) often with own algorithm of resolving
Uids&group id from SID in AD forest with trusted domains.
I even don't know how much mess is it with assigning gid number to all AD groups - is
it just a piece of cake which MS admins would love? ;(
What could be the safe concept (not IPA yet ) for AD Linux integration with sssd to be on
the safe side against MS decommissioning of Unix Services ?
Best
Longina