question about windows users

[Bartosz Chodzinski]

ok I changed it to default
proxy_requests  = yes
$INCLUDE proxy.conf

/etc/freeradius/certs/Makefile
was
#client.crt: client.csr server.crt server.key index.txt serial
#       openssl ca -batch -keyfile server.key -cert server.crt -in
client.csr  -key $(PASSWORD_SERVER) -out client.crt -extensions xpclient_ext
-extfile xpextensions -config ./client.cnf

is now:
client.crt: client.csr ca.pem ca.key index.txt serial
        openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr  -key
$(PASSWORD_SERVER) -out client.crt -extensions xpclient_ext -extfile
xpextensions -config ./client.cnf


changes in client.cnf
was:
certificate             = $dir/server.pem
serial                  = $dir/serial
private_key             = $dir/server.key
commonName              = user at example.com

is now:
certificate             = $dir/ca.pem
serial                  = $dir/serial
private_key             = $dir/ca.key
commonName              = user_certificate


now after instalation ca.der and client.p12 in windows everything in
certificate stores seams to be ok.
there is no exclamation mark on user_certificate, and certification path is
ok

back to the server:

Ready to process requests.
rad_recv: Access-Request packet from host 192.168.5.206 port 1812, id=240,
length=147
        NAS-IP-Address = 192.168.5.206
        NAS-Port = 50046
        NAS-Port-Type = Ethernet
        User-Name = "user_certificate"
        Called-Station-Id = "00-0C-30-81-9B-EE"
        Calling-Station-Id = "00-0A-E4-13-1A-02"
        Service-Type = Framed-User
        Framed-MTU = 1500
        EAP-Message = 0x0200001501757365725f6365727469666963617465
        Message-Authenticator = 0x0d65a52fd78035c3c828c30d2a2442d9
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "user_certificate", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 0 length 21
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[unix] returns notfound
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user.  Authentication
may fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type md5
rlm_eap_md5: Issuing Challenge
++[eap] returns handled
Sending Access-Challenge of id 240 to 192.168.5.206 port 1812
        EAP-Message = 0x0101001604100c91af03e9cd5c25126407d36f22684a
        Message-Authenticator = 0x00000000000000000000000000000000
        State = 0xb5a5cfd0b5a4cb20491e5ee122e4a622
Finished request 0.
Going to the next request




On Wed, May 20, 2009 at 2:39 PM, Ivan Kalik <tnt at kalik.net> wrote:

> >>> The steps you took show that you are NOT following the guide.
> >>>  Good luck.  You clearly are *not* interested in solving the problem.
> >
> > the guide in radiusd.conf says:
> > #The server has proxying turned on by default.  If your system is NOT
> > #  set up to proxy requests to another server, then you can turn proxying
> > #  off here.  This will save a small amount of resources on the server.
> > I tried to read carefully with undrestanding, I dont use proxy, my system
> > not sending request to another server, so I turned it off.
>
> You might not want to, but you *are* proxying your requests. You have
> created client certificate with predefined data in client.cnf - which is
> part of the proxy demonstration setup. So, leave proxy settings alone and
> concentrate on doing what you have been advised - changing data in
> client.cnf so created client certificate won't have @example.com as part
> of the username.
>
> Ivan Kalik
> Kalik Informatika ISP
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090520/dace037b/attachment.html>