2:53 p.m.
I'm triing to use Samba4rc5 like autenticator for Ovirt 3.1.0-3.26
First problem is Ovirt is user usernameprincipal (login@domain in place of
login) to autenticate with Samba4, But samba4 don't use it.
I use
engine-manage-domains -action=add -domain=DOMAINFQDN -user=LOGIN
-provider=ActiveDirectory -interactive -addPermissions
And the result is:
No user in Directory was found for LOGIN@DOMAINFQDN. Trying next LDAP
server in list
Failure while testing domain DOMAINFQDN. Details: No user information was
found for user
And the Samba4 give me:
filter=(&(sAMAccountType=805306368)(userPrincipalName=LOGIN@DOMAINFQDN))
But no userPrincipalName is configured in any user.
Actual Solution: I add a userPrincipalName LOGIN@DOMAINFQDN in the LOGIN
account (using a ldap tool) and add the ovirt machine to the domain.
After restart the ovirt engine I go to the UserPortal.
I find now other problem, the user isn't search by the Common Name (cn), a
example of search
filter=(&(sAMAccountType=805306368)(|(givenname=TESTLOGIN)(sn=TESTLOGIN)(samaccountname=TESTLOGIN)(userPrincipalName=TESTLOGIN)))
must be
filter=(&(sAMAccountType=805306368)(|(givenname=TESTLOGIN)(cn=TESTLOGIN)(sn=TESTLOGIN)(samaccountname=TESTLOGIN)(userPrincipalName=TESTLOGIN)))
Thanks for all
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com
4:15 p.m.
Hi ALejandro,
Officially we're not supporting Sambra4rc5, but I talked with Alon
Bar-Lev (CC'ed) and he explained me Sambra4rc5 is 2003 AD compliant.
On 11/13/2012 03:53 PM, Alejandro wrote:
I'm triing to use Samba4rc5 like autenticator for Ovirt
3.1.0-3.26
First problem is Ovirt is user usernameprincipal (login@domain in place
of login) to autenticate with Samba4, But samba4 don't use it.
I use
engine-manage-domains -action=add -domain=DOMAINFQDN -user=LOGIN
-provider=ActiveDirectory -interactive -addPermissions
And the result is:
No user in Directory was found for LOGIN@DOMAINFQDN. Trying next LDAP
server in list
Failure while testing domain DOMAINFQDN. Details: No user information
was found for user
And the Samba4 give me:
filter=(&(sAMAccountType=805306368)(userPrincipalName=LOGIN@DOMAINFQDN))
But no userPrincipalName is configured in any user.
Actual Solution: I add a userPrincipalName LOGIN@DOMAINFQDN in the LOGIN
account (using a ldap tool) and add the ovirt machine to the domain.
Not sure I fully understood your solution - does this mean you added
this, was this added to the user objects on your ldap server?
There is a reason why we query for userPrincipalName so it has to
include this information.
After restart the ovirt engine I go to the UserPortal.
I find now other problem, the user isn't search by the Common Name (cn),
a example of search
filter=(&(sAMAccountType=805306368)(|(givenname=TESTLOGIN)(sn=TESTLOGIN)(samaccountname=TESTLOGIN)(userPrincipalName=TESTLOGIN)))
must be
filter=(&(sAMAccountType=805306368)(|(givenname=TESTLOGIN)(cn=TESTLOGIN)(sn=TESTLOGIN)(samaccountname=TESTLOGIN)(userPrincipalName=TESTLOGIN)))
I am not sure why you had to add the cn part, can you elaborate?
Thanks for all
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com <mailto:blainett@jabberes.com>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:55 p.m.
2012/11/13 Yair Zaslavsky <yzaslavs(a)redhat.com>
Hi ALejandro,
Officially we're not supporting Sambra4rc5, but I talked with Alon Bar-Lev
(CC'ed) and he explained me Sambra4rc5 is 2003 AD compliant.
Hi Yair
I know it, but is very interesting the idea to avoid Microsoft solutions
and move to OpenSource Enviroment.
I am not sure why you had to add the cn part, can you elaborate?
I find the problem, isn't the cn, only when the user has a
userPrincipalName is find by ovirt.
Probably will be a problem in migration from samba3 to samba4, will quest
in samba4 technical list.
Thanks
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com
5:08 p.m.
On 11/13/2012 05:55 PM, Alejandro wrote:
2012/11/13 Yair Zaslavsky <yzaslavs(a)redhat.com <mailto:yzaslavs@redhat.com>>
Hi ALejandro,
Officially we're not supporting Sambra4rc5, but I talked with Alon
Bar-Lev (CC'ed) and he explained me Sambra4rc5 is 2003 AD compliant.
Hi Yair
I know it, but is very interesting the idea to avoid Microsoft solutions
and move to OpenSource Enviroment.
we do support a few other directory solutions (like freeIPA and 389ds).
389ds needs a kerberos enhancement.
I am not sure why you had to add the cn part, can you elaborate?
I find the problem, isn't the cn, only when the user has a
userPrincipalName is find by ovirt.
Probably will be a problem in migration from samba3 to samba4, will
quest in samba4 technical list.
Thanks
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com <mailto:blainett@jabberes.com>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:40 p.m.
FreeIPA is a microsoft "clone" solution. It is an emulator for AD,
much like Samba4 is. Neither of them is based on Open Standards,
although both are Open Source. This is a very important distinction.
In our test RHEVM environment, only closed-source, proprietary
Microsoft Active Directory could provide a fully functional user
provisioning interface. We attempted OpenLDAP, FreeIPA, and Samba4
but after a couple of weeks the bosses got tired of the slow progress,
threw up their hands and told us to just use Microsoft. This
situation led directly to the replacement of half a dozen production
Red Hat servers with Microsoft Hyper-V hosted Windows servers.
Essentially, this one shortcoming (inability to use OpenLDAP as an AAA
source) ended up driving the abandonment of Open Source in our
enterprise. We're currently in the process of replacing all our FOSS
infrastructure in DNS, DHCP, NTP, LDAP, etc. with ADS and there's
nothing I can do to stop that.
http://en.wikipedia.org/wiki/For_Want_of_a_Nail_%28proverb%29
It's very unfortunate. Law of unintended consequences I guess. I
would like to help oVirt gain compatibility with standards-based
services like OpenLDAP, but the code's in a language I haven't used
and a version control system I haven't used and the wiki has no LDAP
interaction design documents (other than the sources themselves) and
I've got very limited free time, all of which makes it hard to
contribute.
I hope that didn't sound too much like whining. I don't blame anyone
outside my organization for my organization's bad decisions, I'm just
pointing out that giving your userbase no option other than to
implement proprietary Directory models may have unintended
consequences in the field. Why spend a lot of money pretending to be
Microsoft when you can be Microsoft for the same or less money?
--Charlie
> I know it, but is very interesting the idea to avoid Microsoft
solutions
> and move to OpenSource Enviroment.
we do support a few other directory solutions (like freeIPA and 389ds).
389ds needs a kerberos enhancement.
Kerberos should be optional. Many organizations don't need the extra
complexity, LDAP STARTTLS or LDAPS gives them all the security they
need.
9:46 p.m.
----- Original Message -----
From: "Charlie" <medievalist(a)gmail.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "users" <users(a)ovirt.org>
Sent: Tuesday, November 13, 2012 10:40:34 PM
Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
FreeIPA is a microsoft "clone" solution. It is an emulator for AD,
much like Samba4 is. Neither of them is based on Open Standards,
although both are Open Source. This is a very important distinction.
In our test RHEVM environment, only closed-source, proprietary
Microsoft Active Directory could provide a fully functional user
provisioning interface. We attempted OpenLDAP, FreeIPA, and Samba4
but after a couple of weeks the bosses got tired of the slow
progress,
threw up their hands and told us to just use Microsoft. This
situation led directly to the replacement of half a dozen production
Red Hat servers with Microsoft Hyper-V hosted Windows servers.
Essentially, this one shortcoming (inability to use OpenLDAP as an
AAA
source) ended up driving the abandonment of Open Source in our
enterprise. We're currently in the process of replacing all our FOSS
infrastructure in DNS, DHCP, NTP, LDAP, etc. with ADS and there's
nothing I can do to stop that.
http://en.wikipedia.org/wiki/For_Want_of_a_Nail_%28proverb%29
It's very unfortunate. Law of unintended consequences I guess. I
would like to help oVirt gain compatibility with standards-based
services like OpenLDAP, but the code's in a language I haven't used
and a version control system I haven't used and the wiki has no LDAP
interaction design documents (other than the sources themselves) and
I've got very limited free time, all of which makes it hard to
contribute.
I hope that didn't sound too much like whining. I don't blame anyone
outside my organization for my organization's bad decisions, I'm just
pointing out that giving your userbase no option other than to
implement proprietary Directory models may have unintended
consequences in the field. Why spend a lot of money pretending to be
Microsoft when you can be Microsoft for the same or less money?
Not at all.
I feel the same, we really need to support openldap without krb and with krb.
Alon.
--Charlie
>> I know it, but is very interesting the idea to avoid Microsoft
>> solutions
>> and move to OpenSource Enviroment.
>
>
> we do support a few other directory solutions (like freeIPA and
> 389ds).
> 389ds needs a kerberos enhancement.
>
Kerberos should be optional. Many organizations don't need the extra
complexity, LDAP STARTTLS or LDAPS gives them all the security they
need.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:07 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Charlie" <medievalist(a)gmail.com>
Cc: "users" <users(a)ovirt.org>
Sent: Tuesday, November 13, 2012 10:46:37 PM
Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
----- Original Message -----
> From: "Charlie" <medievalist(a)gmail.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "users" <users(a)ovirt.org>
> Sent: Tuesday, November 13, 2012 10:40:34 PM
> Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
>
> FreeIPA is a microsoft "clone" solution. It is an emulator for AD,
> much like Samba4 is. Neither of them is based on Open Standards,
> although both are Open Source. This is a very important
> distinction.
>
> In our test RHEVM environment, only closed-source, proprietary
> Microsoft Active Directory could provide a fully functional user
> provisioning interface. We attempted OpenLDAP, FreeIPA, and Samba4
> but after a couple of weeks the bosses got tired of the slow
> progress,
> threw up their hands and told us to just use Microsoft. This
> situation led directly to the replacement of half a dozen
> production
> Red Hat servers with Microsoft Hyper-V hosted Windows servers.
> Essentially, this one shortcoming (inability to use OpenLDAP as an
> AAA
> source) ended up driving the abandonment of Open Source in our
> enterprise. We're currently in the process of replacing all our
> FOSS
> infrastructure in DNS, DHCP, NTP, LDAP, etc. with ADS and there's
> nothing I can do to stop that.
>
> http://en.wikipedia.org/wiki/For_Want_of_a_Nail_%28proverb%29
>
> It's very unfortunate. Law of unintended consequences I guess. I
> would like to help oVirt gain compatibility with standards-based
> services like OpenLDAP, but the code's in a language I haven't used
> and a version control system I haven't used and the wiki has no
> LDAP
> interaction design documents (other than the sources themselves)
> and
> I've got very limited free time, all of which makes it hard to
> contribute.
>
> I hope that didn't sound too much like whining. I don't blame
> anyone
> outside my organization for my organization's bad decisions, I'm
> just
> pointing out that giving your userbase no option other than to
> implement proprietary Directory models may have unintended
> consequences in the field. Why spend a lot of money pretending to
> be
> Microsoft when you can be Microsoft for the same or less money?
Not at all.
I feel the same, we really need to support openldap without krb and
with krb.
+10 here (not to say we really need to extract all our query/attribute mapping logic in
such way we can further ease integration with new ldap proiders).
Alon.
> --Charlie
>
> >> I know it, but is very interesting the idea to avoid Microsoft
> >> solutions
> >> and move to OpenSource Enviroment.
> >
> >
> > we do support a few other directory solutions (like freeIPA and
> > 389ds).
> > 389ds needs a kerberos enhancement.
> >
>
> Kerberos should be optional. Many organizations don't need the
> extra
> complexity, LDAP STARTTLS or LDAPS gives them all the security they
> need.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:30 a.m.
On 11/13/2012 09:40 PM, Charlie wrote:
I would like to help oVirt gain compatibility with standards-based
services like OpenLDAP, but the code's in a language I haven't used
and a version control system I haven't used and the wiki has no LDAP
interaction design documents (other than the sources themselves) and
I've got very limited free time, all of which makes it hard to
contribute.
+1
--
Jiri Belka
jbelka(a)redhat.com
2:50 p.m.
----- Original Message -----
From: "Jiri Belka" <jbelka(a)redhat.com>
To: users(a)ovirt.org
Sent: Wednesday, November 14, 2012 9:30:39 AM
Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
On 11/13/2012 09:40 PM, Charlie wrote:
> I would like to help oVirt gain compatibility with standards-based
> services like OpenLDAP, but the code's in a language I haven't used
> and a version control system I haven't used and the wiki has no
> LDAP
> interaction design documents (other than the sources themselves)
> and
> I've got very limited free time, all of which makes it hard to
> contribute.
+1
We do have some wiki pages that can be useful to set up a development environment, like:
http://wiki.ovirt.org/wiki/Working_with_oVirt_Gerrit
http://wiki.ovirt.org/wiki/Building_oVirt_engine
Architecture page:
http://wiki.ovirt.org/wiki/Architecture
And specifically, there is a wiki page on the LDAP infrastructure, that can give a clue on
what entities we have there, and how to work with them:
http://wiki.ovirt.org/wiki/DomainInfrastructure
--
Jiri Belka
jbelka(a)redhat.com
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
5:41 p.m.
----- Original Message -----
From: "Oved Ourfalli" <ovedo(a)redhat.com>
To: "Jiri Belka" <jbelka(a)redhat.com>, medievalist(a)gmail.com
Cc: users(a)ovirt.org
Sent: Wednesday, November 14, 2012 3:50:45 PM
Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
----- Original Message -----
> From: "Jiri Belka" <jbelka(a)redhat.com>
> To: users(a)ovirt.org
> Sent: Wednesday, November 14, 2012 9:30:39 AM
> Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
>
> On 11/13/2012 09:40 PM, Charlie wrote:
> > I would like to help oVirt gain compatibility with
> > standards-based
> > services like OpenLDAP, but the code's in a language I haven't
> > used
> > and a version control system I haven't used and the wiki has no
> > LDAP
> > interaction design documents (other than the sources themselves)
> > and
> > I've got very limited free time, all of which makes it hard to
> > contribute.
>
> +1
>
We do have some wiki pages that can be useful to set up a development
environment, like:
http://wiki.ovirt.org/wiki/Working_with_oVirt_Gerrit
http://wiki.ovirt.org/wiki/Building_oVirt_engine
Architecture page:
http://wiki.ovirt.org/wiki/Architecture
And specifically, there is a wiki page on the LDAP infrastructure,
that can give a clue on what entities we have there, and how to work
with them:
http://wiki.ovirt.org/wiki/DomainInfrastructure
When looking at OpenLDAP before I remember the issue was that we didn't have any
standard schema to work with, that had all the different attributes we need.
Currently, we require to authenticate to a Kerberos server. Also, the configuration of the
different provider queries is done inside the source code, and not configured externally.
So, IMO the best way to add a new OpenLDAP provider is first to externalize this
configuration, so that anyone can tweak it out according to his schema.
I hope the wiki pages above can give a clue on the infrastructure, but we would be more
than happy to help guiding you about that.
The relevant people are Yair Zaslavsky (yzaslavs(a)redhat.com), and Roy Golan
(rgolan(a)redhat.com), and myself, which did the latest work on this infrastructure, so we
would be more than happy to help on IRC, E-mails, phone calls, and etc.
Another relevant mailing list is engine-devel(a)ovirt.org, where most engine developers are,
so that's the best place to get guidance regarding git, gerrit, java, and every
development matter.
Oved
> --
>
> Jiri Belka
> jbelka(a)redhat.com
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
5:50 p.m.
Oved, totally agree about externalizing the configuration. Also I
like Roy Golan's recommendation of a wiki design page, because I can
probably offer more in the design phase than the actual coding phase.
I know the OpenLDAP schema interface rather well, and I have my own
OID so I can define globally useful oVirt schema for you if you'd like
to go that route.
You guys are always very helpful and encouraging, which is why this
project moves so fast.
--Charlie
On Wed, Nov 14, 2012 at 11:41 AM, Oved Ourfalli <ovedo(a)redhat.com> wrote:
----- Original Message -----
> From: "Oved Ourfalli" <ovedo(a)redhat.com>
> To: "Jiri Belka" <jbelka(a)redhat.com>, medievalist(a)gmail.com
> Cc: users(a)ovirt.org
> Sent: Wednesday, November 14, 2012 3:50:45 PM
> Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
>
>
>
> ----- Original Message -----
> > From: "Jiri Belka" <jbelka(a)redhat.com>
> > To: users(a)ovirt.org
> > Sent: Wednesday, November 14, 2012 9:30:39 AM
> > Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
> >
> > On 11/13/2012 09:40 PM, Charlie wrote:
> > > I would like to help oVirt gain compatibility with
> > > standards-based
> > > services like OpenLDAP, but the code's in a language I haven't
> > > used
> > > and a version control system I haven't used and the wiki has no
> > > LDAP
> > > interaction design documents (other than the sources themselves)
> > > and
> > > I've got very limited free time, all of which makes it hard to
> > > contribute.
> >
> > +1
> >
>
> We do have some wiki pages that can be useful to set up a development
> environment, like:
> http://wiki.ovirt.org/wiki/Working_with_oVirt_Gerrit
> http://wiki.ovirt.org/wiki/Building_oVirt_engine
>
> Architecture page:
> http://wiki.ovirt.org/wiki/Architecture
>
> And specifically, there is a wiki page on the LDAP infrastructure,
> that can give a clue on what entities we have there, and how to work
> with them:
> http://wiki.ovirt.org/wiki/DomainInfrastructure
>
When looking at OpenLDAP before I remember the issue was that we didn't have any
standard schema to work with, that had all the different attributes we need.
Currently, we require to authenticate to a Kerberos server. Also, the configuration of
the different provider queries is done inside the source code, and not configured
externally.
So, IMO the best way to add a new OpenLDAP provider is first to externalize this
configuration, so that anyone can tweak it out according to his schema.
I hope the wiki pages above can give a clue on the infrastructure, but we would be more
than happy to help guiding you about that.
The relevant people are Yair Zaslavsky (yzaslavs(a)redhat.com), and Roy Golan
(rgolan(a)redhat.com), and myself, which did the latest work on this infrastructure, so we
would be more than happy to help on IRC, E-mails, phone calls, and etc.
Another relevant mailing list is engine-devel(a)ovirt.org, where most engine developers
are, so that's the best place to get guidance regarding git, gerrit, java, and every
development matter.
Oved
> > --
> >
> > Jiri Belka
> > jbelka(a)redhat.com
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
5:41 p.m.
The domainInfrastructure wiki page is helpful. The examples are
great. It has enough information to understand how oVirt formats an
LDAP filter string, for example, which is very important. The
constant use of the word "domain" is confusing, though.
People outside the Microsoft world don't know that Microsoft
documentation uses three different definitions of domain, sometimes in
the same document. Most people will probably just assume you mean an
IANA domain.
I've worked with LDAP for over ten years, and I read the oVirt
domainInfrastructure page three or four times but I still couldn't
figure out why it kept talking about domains and LDAP at the same time
until I took a week of AD classes and studied a couple of O'Reilly AD
books.
For example, when the oVirt wiki talks about "root DSE for domain" it
doesn't make sense to anyone who isn't already familiar with AD. A
rootDSE describes the configuration of a DSA instance (LDAP server
daemon) as defined in RFC4512 section 5.1, and doesn't have anything
to do with domains. The word domain does not occur in RFC4512 or
RFC2251 at all. The page doesn't explain why oVirt needs a domain and
a root DSE to have any special relationship. ISPs load information
for hundreds of IANA domains under a single root DSE and it's not a
problem; I've done five domains in one DSA under one root DSE.
If there was an oVirt wiki page called LDAP or
DirectoryInfrastructure, that page could explain if domains really
need to be part of oVirt, and if so which kind of domain, and then
link the current domainInfrastructure page. Or it could link a
separate page for each directory supported by oVirt, and the current
domainInfrastructure page could become an activeDirectory page and
retain all the AD-specific language.
--Charlie
On Wed, Nov 14, 2012 at 8:50 AM, Oved Ourfalli <ovedo(a)redhat.com> wrote:
----- Original Message -----
> From: "Jiri Belka" <jbelka(a)redhat.com>
> To: users(a)ovirt.org
> Sent: Wednesday, November 14, 2012 9:30:39 AM
> Subject: Re: [Users] Ovirt 3.1 and Samba4 AD
>
> On 11/13/2012 09:40 PM, Charlie wrote:
> > I would like to help oVirt gain compatibility with standards-based
> > services like OpenLDAP, but the code's in a language I haven't used
> > and a version control system I haven't used and the wiki has no
> > LDAP
> > interaction design documents (other than the sources themselves)
> > and
> > I've got very limited free time, all of which makes it hard to
> > contribute.
>
> +1
>
We do have some wiki pages that can be useful to set up a development environment, like:
http://wiki.ovirt.org/wiki/Working_with_oVirt_Gerrit
http://wiki.ovirt.org/wiki/Building_oVirt_engine
Architecture page:
http://wiki.ovirt.org/wiki/Architecture
And specifically, there is a wiki page on the LDAP infrastructure, that can give a clue
on what entities we have there, and how to work with them:
http://wiki.ovirt.org/wiki/DomainInfrastructure
> --
>
> Jiri Belka
> jbelka(a)redhat.com
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
5:56 p.m.
On 11/13/2012 05:55 PM, Alejandro wrote:
2012/11/13 Yair Zaslavsky <yzaslavs(a)redhat.com <mailto:yzaslavs@redhat.com>>
Hi ALejandro,
Officially we're not supporting Sambra4rc5, but I talked with Alon
Bar-Lev (CC'ed) and he explained me Sambra4rc5 is 2003 AD compliant.
Hi Yair
I know it, but is very interesting the idea to avoid Microsoft solutions
and move to OpenSource Enviroment.
+1 on that.
I am not sure why you had to add the cn part, can you elaborate?
I find the problem, isn't the cn, only when the user has a
userPrincipalName is find by ovirt.
That's true, this is how we run the query
of get user by name.
Probably will be a problem in migration from samba3 to samba4, will
quest in samba4 technical list.
Thanks for that, keep us posted, you raised an interesting issue here!
Thanks
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com <mailto:blainett@jabberes.com>
11:03 p.m.
2012/11/13 Yair Zaslavsky <yzaslavs(a)redhat.com>
There is a reason why we query for userPrincipalName so it has to
include
this information.
From
http://theessentialexchange.com/blogs/michael/archive/2007/11/13/the-user...
:
"The user principal name is not a required attribute (that is, Active
Directory does not require it to be set). The new user wizard in ADU&C
makes you set it - but you can go in and delete it from the Account
Properties page later, and when you are creating users programmatically
(such as via scripting), it doesn't need to be specified at all."
Which is the reason to make searchs with a not required attribute?
Thanks
--
Alejandro Escanero Blanco
Consultor de sistemas basados en fuentes abiertas
Desarrollador de FusionDirectory (http://www.fusiondirectory.org)
Blog: http://www.disasterproject.com
Jabber: blainett(a)jabberes.com
4201
days inactive
4202
days old
13 comments
7 participants
participants (7)
-
Alejandro -
Alon Bar-Lev -
Charlie -
Itamar Heim -
Jiri Belka -
Oved Ourfalli -
Yair Zaslavsky